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(54) Tide: ELECTRONIC COMMERCE USING A TRANSACTION NETWORK 

(57) Abstract 

The present invention is directed to a transaction 
network that facilitates and simplifies purchase transac- 
tions between any number of customers and any number 
of merchants. The transaction network is primarily uti- 
lized in the sale and purchase of digital content via a net- 
work such as the Internet. The transaction network reg- 
isters and authenticates customer purchase activities and 
maintains customer account data including payment in- 
formation. Once registered, a customer will generally not 
register again for further purchase activities at participat- 
ing merchant sites. Additionally, the transaction network 
provides a single, central authentication mechanism for all 
participating merchant sites using a single customer iden- 
tifier and password. Further, the transaction network ac- 
cumulates purchase information across all of the merchant 
sites and the ultimate payment processing of those pur- 
chase transactions. Payment processing generally occurs 
on a periodic basis, enabling the accumulation of multiple 
purchase transactions within a participating customer's ac- 
count. The network additionally preferably provides cus- 
tomers with centralized, automated services for customer 
account management, product refunds, subscription man- 
agement, and multiple purchasing accounts linked to the 
same payment account 
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ELECTRONIC COMMERCE USING A TRANSACTION NETWORK 

TECHNICAL FIELD 

The present invention is directed to the field of electronic commerce, 
and more particularly, to the field of facilitating user registration and authentication, 
5 purchasing from multiple merchants, aggregating payment transactions, and merchant 
remittance for electronic commerce transactions, such as those conducted on the 
Internet. 

BACKGROUND OF THE INVENTION 

The World Wide Web ("the Web") is an interactive computer 

to environment. The Web uses a collection of common protocols, including the 
Hypertext Transfer Protocol ("HTTP"), and file formats, including Hypertext Markup 
Language ("HTML"), to enable users to obtain information from or exchange 
information with a huge number of organizations, via the Internet, from virtually 
anywhere in the world. In order to establish a presence on the Web, organizations 

15 generally construct a "Web site." Such a Web site generally includes a collection of 
documents relating to the organization that is accessible by users using an address on 
the Web, called a Universal Resource Locator ("URL"), publicized by the 
organization. 

The Web is increasingly used as a channel for commercial activity. 

20 Many organizations have achieved great success at selling products and services 
through their Web sites. For instance, a significant fraction of the airline tickets, 
music compact discs, and books sold today are sold via the Web. 

In order to attract customers for such sales, a merchant must generally 
advertise its Web site on the Web or another more traditional media, or otherwise pay 

25 to attract customers. In most such sales, the purchase price is paid using a credit card 
or check card. In order to complete such a purchase, the customer provides to the 
merchant information associated with the credit card or check card, such as the 
number and expiration date of the credit card or check card. The customer commonly 
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also provides additional information about himself or herself, such as name and postal 
address for delivering physical goods. 

The merchant uses the provided credit card or debit card information 
to generate a request for payment of the purchase price, which it transmits to a 
5 payment processor. The payment processor in turn charges the purchase price to the 
customer's credit card or check card, and credits the merchant's account in the 
amount of the purchase price. For a particular customer, this process is general! y 
repeated for each merchant from which the customer makes a purchase. Similarly, a 
merchant generally repeats this process for each purchase made by a customer. 

10 The foregoing approach is efficient for purchases having a significant 

purchase price, such as those above US$ 20. However, because a significant portion 
of the actual costs of processing a credit card or check card transaction are fixed and 
not related to the amount of the transaction, processing credit card transactions for 
lower amounts is generally cost-prohibitive. As a result, credit card and check card 

15 transactions are generally not used to purchase goods and services having a relatively 
low price, such as those below US$ 20. Additionally, the high cost of providing 
customer service on the Internet, including such recurring operations as supplying 
lost passwords, raises the cost for selling goods, thus raising the minimum price at 
which goods must be sold to realize a profit. 

20 While other forms of payment, such as cash proxies, have been 

proposed for use in such lower-priced transactions, these other forms of payment 
have failed to achieve acceptance on the Web. This is largely due to the amount of 
extra interaction that these cash proxy payment methods require from the customer, 
as customers are often unwilling to tolerate a great deal of inconvenience to purchase 

25 an inexpensive item. Moreover, even if such an alternative form of payment did 
achieve acceptance on the Web, they typically impose significant processing costs on 
those merchants that accept them, and do nothing to alleviate customer service costs. 

Since credit card and check card transactions are the only forms of 
payment that have achieved general acceptance on the Web, it is generally not 

30 possible to buy such lower-priced goods and services on the Web. These lower- 
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priced purchases are, however, important. In particular, digital goods, such as 
electronic magazine articles, music, or games, delivered via the Web have a very 
small marginal cost. While there may be a significant demand for some digital goods 
if priced at appropriately modest levels, when their price is set at or above the 
5 minimum viability threshold for credit card and check card transactions, demand is 
very low or nonexistent. Therefore, because goods cannot be sold via credit card or 
check card at a price below the minimum viability threshold, and there is little 
demand at or above the minimum viability threshold, such goods are incapable of 
generating significant revenue and generally are not offered for sale. 

10 The transactional model discussed above, in which customers make 

purchases directly from merchants using credit card or check card transactions, have 
serious disadvantages for both customers and merchants. First, as noted above, low- 
priced purchases are generally impossible to conduct using this model, which 
generally precludes customers from purchasing and merchants from selling certain 

15 products, and limits the number of customers that can purchase others. Further, the 
model requires each customer to expend significant effort managing his or her 
relationship with each merchant, and also requires each merchant to make significant 
up-front and continuing investments in managing its relationship with its customers 
and with its payment processor. 

20 Figure 1 is a relationship diagram showing the relationships arising 

between customers, merchants, and payment processors in accordance with the 
conventional transaction model. The diagram show r s a number of customers 110, 
who engage in purchase transactions with a number of merchants 120. Each line 
between a customer 110 and a merchant 120 represents a relationship between the 

25 customer and the merchant that must be managed by both the customer and the 
merchant. 

From the customer's perspective, he or she must provide credit card or 
check card payment information to each new merchant from which the customer 
makes a purchase. To do so is generally both inconvenient, because the customer 
30 must enter the same information over and over, and disconcerting, because the 
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customer is required to entrust this sensitive information to several different parties, 
one or more of which may be untrustworthy. In addition, customers must learn the 
customer service policies of every merchant from which they purchase, which can be 
a burdensome process, especially for modestly-priced purchases. 
5 From the merchant's perspective, it must build, operate, and scale up 

an infrastructure for accepting credit or check card payments from customers, for 
delivering purchased goods, and for providing customer service to those customers. 
Such infrastructures are generally expensive, and often distract merchants from their 
more fundamental role of creating and selling products. 
10 Further disadvantages arise in the conventional model when a 

merchant subjects customers to user authentication. Merchants often use user 
authentication, the process of establishing that a Web user is actually a returning 
customer, to enable customers to make subsequent purchases using the payment 
information from a previous purchase, or to facilitate continuing consumption of 
15 purchased goods, such as continued access to an online periodical to which the 
customer has purchased a subscription. Generally, in order to authenticate as a 
returning customer, a user must enter a user name and password that is specific to 
each merchant. From the customer's perspective, submitting to user authentication 
involves the disadvantages of having to use a user name that is unique among those of 

20 each merchant's customers and thus is not always freely chosen by the customer, 
having to remember or record each of these different member names, and having to 
re-authenticate each time the customers move from the Web site of one merchant to 
the Web site of another, which can prove burdensome and frustrating for users. 

From the merchant's perspective, performing user authentication 

25 involves the disadvantages of having to build, operate, and scale up a mechanism for 
performing user authentication and a customer database to support user 
authentication, an effort that is potentially both costly and distracting. In addition to 
relationships with its customers, in the conventional model a merchant must also 
maintain a relationship with a payment processor 1 30 to process credit or check card 

30 transactions. Maintaining a relationship with a payment processor requires the 
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merchant to shop for and negotiate a contract with a payment processor, and to build, 
operate, and scale up a mechanism for communicating with the payment processor, 
another effort that is potentially both costly and distracting. 

It can be seen from the foregoing that, from the perspective of 
5 merchants, a reliable system for selling goods, including lower-priced goods on the 
Web, without having to develop an infrastructure for accepting payment, for 
registering and authenticating customers would have significant utility, or for 
providing customer support. It can further be seen that, from the perspective of 
customers, a convenient system that facilitates the purchase of goods, including 
10 lower-priced goods from a number of different merchants without having to submit 
payment information to each merchant or reauthenticate to each merchant, and which 
provides centralized customer service for purchases made from multiple merchants 
would also have significant utility. 

SUMMARY OF THE INVENTION 

15 The present invention provides a new type of transaction network ("the 

network") for facilitating purchase transactions between any number of customers 
and any number of merchants participating in the network. The network is well- 
suited to the purchase of low-priced "digital goods," as well as the purchase of other 
products and services, especially those having relatively low prices, and enables 

20 customer to use traditional forms of payment, such as credit cards. The network 
relieves merchants of the burdens of each maintaining a separate infrastructure for 
authenticating and accepting payment from customers, delivering goods, and 
providing customer service. The network further provides a single registration 
process during which the customer provides credit card payment information once for 

25 all of the merchants, as well as universal authentication to the Web sites of all of the 
merchants through a single user interaction. The network yet further facilitates the 
migration of large existing groups of users from other authentication systems, such as 
those of merchants, to the authentication system provided by the network. The 
network additionally preferably provides customers with centralized, automated 



BNSDOC1D: <WO 0033221 A1 _1_> 



WO 00/33221 



6 



PCT/US99/27879 



services for customer account management, product refunds, subscription 
management, and multiple purchasing accounts linked to the same payment account. 

Figure 2 is a relationship diagram showing the relationships defined 
for customers and merchants by the network. It can be seen that each customer 210, 
5 rather than maintaining a separate purchasing relationship with each merchant 220, 
need only maintain a single purchasing relationship with the network 240. This 
means that the customer need only provide payment information and to register and 
authenticate to the network, not to each merchant. Similarly, each merchant 220, 
rather than maintaining a relationship with each customer 210, need only maintain a 

10 single relationship to the network. This means that, rather than providing 
infrastructure for accepting payment from customers, delivering goods to customers, 
registering and authenticating customers, and providing customer service, the 
merchants may rely upon corresponding functionalities of the network. Further, 
rather than themselves maintaining a relationship with a charge processor 230, the 

15 merchants 220 can rely on the relationship with the charge processor maintained by 
the network 240. Participation in the network thus frees both customers and 
merchants of the substantial burdens of the conventional transaction model described 
above. 

In accordance with the present invention, a new customer may visit the 
20 Web site of any merchant. When the user selects, on the merchant's Web site, a 
product or service (hereafter "item") for purchase, the network determines whether 
the customer is presently registered and authenticated with the network. If the 
customer is not presently registered, the network enables the customer to register with 
the network by providing identity and payment information. The identity information 
25 provided by the customer preferably includes a member identifier and a password for 
use with the network, as well as an electronic mail ("email") address. The payment 
information preferably includes a credit card number, or other information usable to 
charge the customer for purchases. As part of registration process, the network 
preferably verifies the provided payment information. At the conclusion of 
30 registration process, the registered customer is permitted to purchase the item. As a 
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result of the purchase, the purchased item is provided to the customer, and a 
transaction record is created that identifies the customer, the merchant, and the 
amount of the purchase. The visual user interfaces for these registration and purchase 
processes are preferably cobranded with the trademarks of the merchant and the 
5 operator of the network, to indicate that both parties are collaborating in providing the 
purchasing experience enjoyed by the customer. 

After the customer has registered, the customer is effectively signed on 
to the network for a period of time, such as several hours. After registering, the 
customer may again sign on to the network by identifying, "or authenticating," 
10 himself or herself to the network by entering the member identifier and password. 
During the time that the customer is signed on, the customer may browse and 
purchase items from any Web site in the network without repeating the authentication 
process. 

The network periodically reviews the unbilled purchase transaction 
15 records of each customer resulting from purchases made by the customer at any site. 
When the amounts of these records exceed a threshold value, preferably determined 
based upon the amount at which the transaction costs for the form of payment 
provided by the customer become reasonable, the network generates a payment 
request requesting payment of the total amount. The network then combines the 
20 payment requests generated for a number of users and transmits them to a payment 
processor for payment. The payment processor returns a settlement indication for 
each payment request indicating that the payment request has been settled or 
declined. 

At this point, the merchants from whom the customer purchased the 
25 items are each credited with a portion of the corresponding purchase price, and the 
purchase transaction records represented by the payment request are marked as paid. 
In this manner, the network efficiently facilitates purchase transactions having 
relatively low purchase amounts using traditional forms of payment. The network 
further facilitates purchases having relatively low prices by providing centralized 
30 services for seeking refunds and managing subscriptions, and by providing multiple 
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purchasing accounts linked to a single payment account. By providing these 
customer service functionalities to merchants, the network substantially lowers 
merchants' transaction processing costs, thereby enabling merchants to offer for sale 
modestly-priced goods. 
5 In a further embodiment, during registration, the network permits the 

customer to provide a member identifier that is not unique among all of the customers 
of the network. In this embodiment, the network stores a unique identifier for the 
customer, along with the member identifier specified by the customer, in a cookie on 
the customer's computer system. When the customer subsequently authenticates by 

10 providing the member identifier, the network uses the member identifier to find the 
unique identifier on the customer's computer system, and uses the member identifier 
together with the unique identifier to authenticate the customer. In this way, the 
network allows customers to use non-unique member identifiers. This improves the 
customer experience for all customers, as it enables them to choose a particular 

15 member identifier without regard for its use by other customers. This is especially 
valuable where the network has a large number of customers. Facilitating non-unique 
member identifiers also permits the operator of the network to "absorb" or "imporf ' 
existing groups of customers from other online services, where they already have 
member identifiers to which they are accustomed, and which may be redundant with 

20 the member identifiers of other customers of the network. 



BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 is a relationship diagram showing the relationships arising 
between customers, merchants, and payment processors in accordance with the 
conventional transaction model. 
25 Figure 2 is a relationship diagram showing the relationships defined 

for customers and merchants by the network. 

Figure 3 is a high-level block diagram of the computer network 
environment in which the transaction network preferably operates. 
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Figure 4 is a high-level block diagram of a typical merchant computer 

system. 

Figure 5 is a high-level block diagram of a typical customer computer 

system. 

5 Figure 6 is a high-level block diagram of a typical network service 

center computer system. 

Figure 7 is a screen shot diagram showing a Web page displayed by a 

merchant. 

Figure 8 is a flow diagram showing the steps preferably performed by 
10 the network as part of the purchasing process. 

Figure 9 is a flow diagram showing the steps preferably performed by 
the network in order to authenticate a customer. 

Figure 10 is a screenshot diagram showing the sign on dialog 
preferably displayed by the network to collect the member identifier and password. 
15 Figure 1 1 is a flow diagram showing the steps preferably performed by 

the network in order to register the customer with the network. 

Figure 12 is a screenshot diagram showing a registration dialog 1200, 
into which the user enters personal and payment information. 

Figure 13 is a screenshot diagram showing a confirmation dialog 
20 preferably displayed by the network in step 808. 

Figure 14 is a screenshot diagram showing provision of a purchased 

item. 

Figure 15 is a screenshot diagram showing a Web page of a second 

merchant. 

25 Figure 16 is a screenshot diagram showing the confirmation dialog 

displayed in response to the customer's selection of link 1524. 

Figure 17 is a screenshot diagram showing the provision of the 
additional purchased item. 

Figure 18 is a table diagram showing the transaction database 
30 maintained by the network. 
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Figure 19 is a flow diagram of the steps preferably performed by the 
network in order to aggregate the transaction records in the transaction database into 
authorizations sent to a payment processor. 

Figure 20 is a flow diagram showing the steps preferably performed by 
5 the network in order to process a settlement report. 

Figure 21 is a screenshot diagram showing a sample customer 

statement. 

Figure 22 is a screenshot diagram showing a sample item information 

page. 

10 Figure 23 is a screenshot diagram showing a sample refund request. 

Figure 24 is a screenshot diagram showing a sample confirmation 
screen confirming a refund request. 

Figure 25 is a screenshot diagram showing a sample statement 
reflecting the submission of a refund request. 
15 Figure 26 is a screenshot diagram showing a sample subscription 

management page. 

Figure 27 is a screenshot diagram showing a sample subscription 
information page. 

Figure 28 is a screenshot diagram showing a sample registration page 
20 for registering an additional purchasing account for an existing payment account. 

Figure 29 is a screenshot diagram showing a sample customer 
statement showing purchases made with the additional purchasing account. 

Figure 30 is a screenshot diagram showing a sample customer 
statement showing purchases made with multiple purchasing accounts that are each 
25 associated with the same payment account. 

DETAILED DESCRIPTION OF THE INVENTION 

The present invention provides a new type of transaction network ("the 
network") for facilitating purchase transactions between any number of customers 
and any number of merchants participating in the network. The network is well- 
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suited to the purchase of low-priced "digital goods, 1 " as well as the purchase of other 
products and services, especially those having relatively low prices, and enables 
customer to use traditional forms of payment, such as credit cards. The network 
relieves merchants of the burdens of each maintaining a separate infrastructure for 
5 authenticating and accepting payment from customers, delivering goods, and 
providing customer service. The network further provides a single registration 
process during which the customer provides credit card payment information once for 
all of the merchants, as well as universal authentication to the Web sites of all of the 
merchants through a single user interaction. The network yet further facilitates the 

T I0 migration of large existing groups of users from other authentication systems, such as 
those of merchants, to the authentication system provided by the network. The 
network additionally preferably provides customers with centralized, automated 
services for customer account management, product refunds, subscription 
management, and multiple purchasing accounts linked to the same payment account. 

15 Figure 2 is a relationship diagram showing the relationships defined 

for customers and merchants by the network. It can be seen that each customer 210, 
rather than maintaining a separate purchasing relationship with each merchant 220, 
need only maintain a single purchasing relationship with the network 240. This 
means that the customer need only provide payment information to register and 

20 authenticate the network, not to each merchant. Similarly, each merchant 220, rather 

• ; than maintaining a relationship with each customer 210, need only maintain a single 
relationship to the network. This means that, rather than providing infrastructure for 
accepting payment from customers, delivering goods to customers, registering and 
authenticating customers, and providing customer service, the merchants may relay 

25 upon corresponding functionalities of the network. Further, rather than themselves 
maintaining a relationship with a charge processor 230, the merchants 220 can rely on 
the relationship with the charge processor maintained by the network 240. 
Participation in the network thus frees both customers and merchants of the 
substantial burdens of the conventional transaction model described above. 
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In accordance with the present invention, a new customer may visit the 
Web site of any merchant. When the user selects, on the merchant's Web site, a 
product or service (hereafter "item") for purchase, the network determines whether 
the customer is presently registered and authenticated with the network. If the 
5 customer is not presently registered, the network enables the customer to register with 
the network by providing identity and payment information. The identity information 
provided by the customer preferably includes a member identifier and a password for 
use with the network, as well as an electronic mail (/'email") address. The payment 
information preferably includes a credit card number, or other information usable to 

10 charge the customer for purchases. As part of registration process, the network 
preferably verifies the provided payment information. At the conclusion of 
registration process, the registered customer is permitted to purchase the item. As a 
result of the purchase, the purchased item is provided to the customer, and a 
transaction record is created that identifies the customer, the merchant, and the 

15 amount of the purchase. The visual user interfaces for these registration and purchase 
processes are preferably cobranded with the trademarks of the merchant and the 
operator of the network, to indicate that both parties are collaborating in providing the 
purchasing experience enjoyed by the user. 

After the customer has registered, the customer is effectively signed 

20 on to the network for a period of time, such as several hours. After registering, the 
customer may again sign on to the network by identifying, "or authenticating," 
himself or herself to the network by entering the member identifier and password. 
During this time that the customer is signed on, the customer may browse and 
purchase items from any Web site in the network without repeating the authentication 

25 process. 

The network periodically reviews the unbilled purchase transaction 
records of each customer resulting from purchases made by the customer at any site. 
When the amounts of these records exceed a threshold value, preferably determined 
based upon the amount at which the transaction costs for the form of payment 
30 provided by the customer become reasonable, the network generates a payment 



BNSDOCIO: <WO 0033221 A1 _l_> 



WO 00/33221 

13 

request requesting payment of the total amount. The network then combines the 
payment requests generated for a number of users and transmits them to a payment 
processor for payment. The payment processor returns a settlement indication for 
each payment request indicating that the payment request has been settled or 
5 declined. 

At this point, the merchants from whom the customer purchased the 
items are each credited with a portion of the corresponding purchase price, and the 
purchase transaction records represented by the payment request are marked as paid. 
In this manner, the network efficiently facilitates purchase transactions having 

id relatively low purchase amounts using traditional forms of payment. The network 
further facilitates purchases having relatively low prices by providing centralized 
services for seeking refunds and managing subscriptions, and by providing multiple 
purchasing accounts linked to a single payment account. By providing these 
customer service functionalities to merchants, the network lowers their transaction 

15 processing cost substantially, thereby enabling merchants to offer for sale modestly- 
priced goods. 

In a further embodiment, during registration, the network permits the 
customer to provide a member identifier that is not unique among all of the customers 
of the network. In this embodiment, the network stores a unique identifier for the 

20 customer, along with the member identifier specified by the customer, in a cookie on 
the customer's computer system. When the customer subsequently authenticates by 
providing the member identifier, the network uses the member identifier to find the 
unique identifier on the customer's computer system, and uses the member identifier 
together with the unique identifier to authenticate the customer. In this way, the 

25 network allows customers to use non-unique member identifiers. This improves the 
customer experience for all customers, as it enables them to choose a particular 
member identifier without regard for its use by other customers. This is especially 
valuable where the network has a large number of customers. Facilitating non-unique 
member identifiers also permits the operator of the network to "absorb" or "import" 

30 existing groups of customers from other online services, where they already have 
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member identifiers to which they are accustomed, and which may be redundant with 
the member identifiers of other customers of the network. 

Figure 3 is a high-level block diagram of the computer network 
environment in which the transaction network preferably operates. Merchant 
5 computer systems 310 are computer systems operated by or on behalf of merchants 
that make items available for purchase by customers of the network. Merchant 
computer systems 310 preferably each provide a Web server that serves Web pages, 
some of which offer items for sale. The merchant computer systems 310 are 
connected to customer computer systems 330 via a network 320, such as the Internet. 

10 The customer computer systems 330 are usable by customers to browse the Web 
pages served by the merchant computer systems 310. When doing such browsing, a 
customer may use a customer computer system 330 to purchase an item offered for 
sale. Such purchase is communicated over the network 320 to a network service 
center computer system, which makes a record of the transaction. The network 

15 service center computer system 340 periodically collects together transactions entered 
into by each user, aggregates them into requests for payment, and forwards these 
payment requests over a secure network 350 to a payment processor computer system 
360 for payment. The configurations of several of the computer systems shown in 
Figure 3 are discussed below in conjunction with Figures 4-6. While the network is 

20 preferably implemented on computer systems configured in this manner, those skilled 
in the art will recognize that the network may be advantageously implemented on 
combinations of computer systems other than those shown in these figures. 

Figure 4 is a high-level block diagram of a typical merchant computer 
system. The merchant computer system 310 includes one or more central processing 

25 units ("CPUs") 410, and a network connection 420 for connecting to the network 320. 
The merchant computer system further comprises computer storage 430, which may 
include both transient storage devices, such as random access memory, and persistent 
storage devices, such as hard drives. The storage preferably includes an HTTP server 
program 431 for serving Web pages 432 offering items for sale. The storage 

30 preferably also includes: a product database 433 for storing items offered for sale; a 
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transaction engine 434 provided by the operator of the network to conduct the sale 
and delivery of items to authenticated customers and an authorization subsystem 
program 435, provided by the operator of the network to manage authorization of 
" customers to the merchant Web site. The merchant computer system further includes 
5 ■ - a computer-readable media drive 440, which can be used to install software products, 
including the network, which are provided on a removable computer-readable 
medium, such as a CD-ROM or a DVD. 

Figure 5 is a high-level block diagram of a typical customer computer 
system. The customer computer system 330 has one or more CPUs 510 and a 
10 network connection 520. The customer computer system further has a visual display 
530, such as a video monitor for displaying Web pages, a keyboard 540 for inputting 
text, and a pointing device 550, such as a mouse, for selecting positions on the 
display. The customer computer system further includes transient and/or persistent 
storage 560 containing a Web browser program 561 for displaying and interacting 
15 with Web pages, and a cookie file 562 containing information stored on the customer 
computer system by Web servers and/or the network. 

Figure 6 is a high-level block diagram of a typical network service 
center computer system. The network service center computer system 340 has one or 
more CPUs 610, a network connection 620, and a computer readable media drive 
20 630. The network service center computer system further includes transient and/or 
" persistent storage 640 containing network service center software 641 for managing 
1 the record keeping associated with purchase transactions, an HTTP server 642 for 
serving Web pages, a customer database 643 for maintaining information on each 
customer of the network, a merchant database 644 for maintaining information about 
25 J each merchant, and a transaction database 645 for maintaining information about 
* transactions entered into between customers and merchants. While these tables, 
described in greater detail below, are each conceptually single tables, they may each 
be implemented using more than one table, or a combination of data structures of 
different types. 
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To more clearly illustrate the operation of the network, its operation is 
described herein in conjunction with an example of its use by a customer. Figure 7 is 
a screen shot diagram showing a Web page displayed by a merchant. The Web page 
700 includes information about the merchant, including information about products 
5 71 1-714 that are offered for sale by the merchant. The information about each item 
includes a link that may be activated by the customer. For example, link 71 1 may be 
activated by the customer to purchase the item "20 Questions on XML." When the 
customer does so, the customer initiates the purchasing process. 

Figure 8 is a flow diagram showing the steps preferably performed by 

10 the network as part of the purchasing process. These steps are preferably performed 
by network service center software executing on the network service center computer 
system and a transaction engine executing on the merchant computer system in 
conjunction with the Web browser executing on a customer computer system. Those 
skilled in the art will recognize, however, that these steps, as well as the other steps 

15 shown in flow diagrams herein, may also be distributed to other computer programs 
executing on other computer systems in accordance with alternate network 
configurations. 

In step 801, the network determines whether a valid session cookie is 
stored on the customer computer system in its cookie file 562. If so, this indicates 

20 that the customer computer system is being used by a registered customer who has 
already signed on to the network, and the network continues in step 807. Otherwise, 
no registered user is currently signed onto the network from the customer computer 
system, and the network continues in step 802. Step 801 is preferably performed by 
examining time stamps in any network session cookies previously stored on the 

25 customer computer system by the network. These time stamps reflect the last time 
the customer signed on and the last time the customer made a purchase. The amount 
of time elapsed between these times stored in the cookie and the present time 
indicates whether each session cookie is presently valid. For example, the network 
may determine that a cookie indicating that the customer signed on less than six hours 
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ago and completed his or her last purchase less than two hours ago is still signed onto 
the network, and that a network session cookie bearing those time stamps is valid. 

In step 802, if the customer is already registered with the network, the 
network permits the customer to sign on, and continues in step 803. If not, the 
5 network allows the user to register with the network, and continues in step 804. In 
step 803, the network authenticates the customer based on information provided by 
the customer as part of a sign on process. Figure 9 is a flow diagram showing the 
steps preferably performed by the network in order to authenticate a customer. In 
step 901, the network collects from the customer the customer's member identifier 

10 and password. Figure 10 is a screenshot diagram showing the sign on dialog box 
preferably displayed by the network to collect the member identifier and password. 
The sign on dialog box 1000 includes a member identifier field 1001 and a password 
field 1002, into which the customer may type his or her member identifier and 
password, respectively. The user then selects the sign on button 1003 to submit this 

15 information. 

In step 902, the network also reads a customer cookie stored on the 
customer computer system for the collected member identifier. In step 903, the 
network extracts from the read customer cookie a unique identifier for the user stored 
in the customer cookie by the network. In one preferred embodiment, this unique 

20 identifier is the user's email address, or other information specific to the domain of 
the user. In step 904, if the combination of the collected user name and the extracted 
unique identifier correspond to a customer entry in the customer database, then the 
network continues in step 905, else authentication fails. In step 905, if the collected 
password is the correct password for that customer entry in the customer database, 

25 then authentication succeeds, else authentication fails. 

; Returning to Figure 8, in step 804, the customer has elected to register 

with the network by activating the register link 1004 in the sign on dialog box 1000. 
Figure 1 1 is a flow diagram showing the steps preferably performed by the network in 
order to register the customer with the network. In step 1101, the network collects 

30 personal information about the customer, as well as payment information. The 
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payment information preferably specifies a credit card account, but may alternatively 
specify any method of payment selected by the operator of the network. The 
collection process is shown in Figure 12. Figure 12 is a screenshot diagram showing 
a registration dialog 1200, into which the user enters personal and payment 
5 information. The user preferably fills in a first name field 1201, a last name field 
1202, a postal code field 1203, an email address field 1204, a credit card type field 
1205, a credit card number field 1206, a credit card expiration date field 1207, a 
member ID field 1208, password fields 1209, and a shared secret field 1210. It 
should be noted that the member ID 1208 may be any member identifier selected by 
10 the user, and does not need to be unique across the network. After completing fields 
1200 through 1210, the user activates the register button 1211 to submit the 
information. 

Returning to Figure 11, in step 1102, the network verifies that the 
entered personal information is formatted correctly. For example, the network 

15 verifies that the zip code in the customer's address has the correct number of digits. 
If personal information formatting verification fails, the network preferably requests 
that the user input new, correctly-formatted personal information and repeats step 
1 102. In step 1 103, the network verifies the entered payment information. In doing 
so, the network preferably determines whether the credit card number is valid, and 

20 whether the personal information collected matches the credit card number. As part 
of determining whether the credit card is valid and active, the network may further 
attempt to obtain authorization to charge a small amount to the credit card, to ensure 
that the credit card is active. The network may further utilize third party credit card 
verification or fraud detection services in performing step 1103. If verification of 

25 payment information fails, the network preferably requests that the user input new, 
valid payment information and repeats step 1 103. In step 1 104, the network creates 
an entry in the customer database for the customer containing the collected 
information. In step 1105, the network sends an email message to the customer 
announcing the customer's successful registration with the network. After step 1 105, 

30 the steps conclude. 
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Returning to Figure 8, after registering the customer, in step 805, the 
network stores on the customer system a customer cookie identifying the customer by 
user name and unique identifier (preferably email address). In step 806, the network 
stores on the customer computer system a network session cookie documenting 
5 customer authentication. The network session cookie preferably includes the date and 
time of authentication. In step 807, the network determines whether the item selected 
by the customer has already been purchased by the customer. If so, the network 
continues in step 81 1 to provide the purchased item without charging the customer 
again. Otherwise, the network continues in step 808. In step 808, the network 

10 confirms the purchase with the customer. Figure 13 is a screenshot diagram showing 
a confirmation dialog preferably displayed by the network in step 808. The 
confirmation dialog 1300 contains information 1301 about the purchase, including an 
identification of the item, the purchase amount, and the duration or expiration of the 
purchase. In order to complete the purchase, the customer activates the continue 

15 button 1302. 

Returning to Figure 8, in step 809, the network generates a purchase 
transaction, which it adds to its transaction database 645. In step 810, the network 
updates the network session cookie stored on the customer computer system to reflect 
the present time as the time of the last purchase. In step 811, the network provides to 

20 the user the purchased item. After step 811, these steps conclude. 

Figure 14 is a screenshot diagram showing provision of a purchased 
item. The Web page 1400 is the purchased item selected by activating link 711 on 
the merchant Web page, "20 Questions on XML." If the user leaves this Web page to 
continue browsing or turns off the customer computer system, the customer can 

25 revisit this purchased item during the duration of the purchase by again selecting its 
link from the merchant Web page. In response, the network immediately provides the 
purchased item without further interaction by the customer once the user is 
authenticated by the network. 

After the customer is authenticated, the customer may complete 

30 additional purchases on the same or different merchant Web pages without 
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reauthenticating. Figure 15 is a screenshot diagram showing a Web page of a second 
merchant- The Web page 1500 lists items 1501-1526 available for purchase. The 
user may select link 1524 in order to select a market report item titled "Electrical 
Power Systems FY 98." After selection of this link, a confirmation dialog is 
5 immediately displayed without requiring the user to perform any authentication 
interactions. 

Figure 16 is a screenshot diagram showing the confirmation dialog 
displayed in response to the customer's activation of link 1524. Once the 
confirmation dialog box 1600 is displayed, the user need only select the continue 
10 button 1601 in order to complete the purchase of this additional item. After selecting 
this button, the "Electrical Power Systems FY 98" report is displayed. Figure 1 7 is a 
screenshot diagram showing the provision of the additional purchased item. Web 
page 1 700 contains the purchased "Electrical Power Systems FY 98" item. 

As a result of each purchase transaction, the transaction engine creates 

15 a transaction record documenting the transaction, which is stored by the transaction 
engine at the merchant site. Periodically, a polling agent within the network service 
center software polls the transaction engine at each merchant site to retrieve any 
transaction records generated on that merchant's site. The polling agent, upon 
retrieving these transactions, stores them each as a row in a transaction database 

20 maintained by the network. The transaction records are preferably aggregated by the 
network periodically into payment requests, which are requests to a payment 
processor to charge the customer's credit card or other form of payment. Figure 18 is 
a table diagram showing the transaction database maintained by the network. While 
the transaction table is shown for clarity as a single database table containing plain 

25 text, it will be appreciated by those skilled in the art that it may be advantageously 
implemented in a more heavily encoded and optimized form using conventional 
database techniques. 

In the transaction table 1 800, each row represents a transaction. Each 
row preferably contains data in at least six columns: a customer column 1801, a 

30 merchant column 1802, an item column 1803, an amount column 1804, an expiration 
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column 1805, and an outstanding column 1806. The customer column preferably 
contains the member ID of the customer that entered into the transaction. For 
example, row 1812 contains the member identifier "Joe User." The merchant column 
identifies the merchant with which the customer entered into the transaction. For 
5 example, row 1812 lists the merchant "Content Partner/' The item column 1803 
preferably identifies the purchased item. For example, in row 1812, the item is the 
"Twenty Questions on XML" item. The price column 1804 preferably contains the 
amount of the purchased item. For example, in row 1812, the price is "US$ 2.50". 
The expiration column 1805 preferably contains the time at which the purchase 

10 expires. For example, for row 1812, the purchase expires at 2:25 p.m. on 
November3, 1998. Finally, the outstanding column 1812 indicates whether the 
customer has yet paid for the purchase. For example, in row 1812, the customer has 
not yet paid for the purchase, so the transaction is still outstanding. 

Figure 19 is a flow diagram of the steps preferably performed by the 

15 network in order to aggregate the transaction records in the transaction database into 
payment requests sent to a payment processor. The transactions are preferably 
aggregated monthly on each customer's monthly billing anniversary, but may be 
aggregated on any other desired schedule. In steps 1901-1907, the network loops 
through each of a plurality of groups of customers. In a preferred embodiment, there 

20 is a separate group of customers for each day of the month, and the loop of steps 
1901-1907 is iterated once per day. In steps 1902-1905, the network loops through 
each customer in the group. In step 1903, the network determines the sum of the 
outstanding transactions of the customer. For example, for customer "Joe User" the 
network would add the amounts of rows 1812 and 1813, "US$ 2.50" and "US$ 1.00", 

25 to determine the sum of US$ 3.50. In step 1904, if the sum is greater than a billing 
threshold, such as US$ 4, then the network continues in step 1905, else the network 
continues in step 1906. In step 1905, the network generates a payment request for the 
determined sum against the credit card, or other form of payment, of the customer. In 
a preferred embodiment, the generated payment request has two parts: an 

30 authorization request, and a settlement request. The authorization request requests 
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the authority to charge the amount, while the settlement request requests actual 
payment of the amount. In step 1906, if additional customers remain for processing, 
the network loops to step 1902 to process the next customer in the group. In step 
1907, the network transmits the payment requests generated in step 1905 to a 
5 payment processor in a batch. In step 1908, each day, the network loops back to step 
1901 to process the next group of customers. 

Generally, for each batch of payment requests transmitted to the 
payment processor, a payment report is received back from the payment processor 
indicating whether each of the payment requests was paid. Figure 20 is a flow 

10 diagram showing the steps preferably performed by the network in order to process a 
payment report. In step 2001, the network receives the payment report from the 
payment processor. In steps 2002-2007, the network loops through each payment 
indication in the payment report. Each payment indication generally corresponds to a 
different one of the payment requests included in the batch. In step 2003, if the 

15 payment indication indicates that the corresponding authorization was paid by the 
payment processor, then the network continues in step 2005, else the network 
continues in step 2004. In step 2004, the network, through inaction, permits the 
constituent transaction records to remain outstanding. The network may also take 
further steps (not shown) to immediately resubmit the payment requests, or to cancel 

20 the account of the customer. After step 2004, the network continues in step 2007. In 
step 2005, the network credits the accounts of the merchants of the constituent 
transactions in accordance with the business arrangement between the merchants and 
the operator of the network. For example, the merchant "Stat USA" may have an 
arrangement with the operator of the network in which the merchant receives ninety 

25 percent of the amount of each purchase. Thus, for transaction record 1813, the 
merchant "Stat USA" would be credited in the amount US$ 0.90. In step 2006, the 
network cancels the outstanding status of the constituent transaction records so that 
they will not be incorporated in any future payment requests. In step 1907, if 
additional payment indications remain in the payment report, the network loops back 
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to step 1902 to process the next payment indication. After step 2007, the steps 
conclude. 

With respect to the steps shown in Figures 19 and 20 and discussed 
above, those skilled in the art will appreciate that, while these steps are directed 
5 primarily to forms of payment such as credit cards and check cards, these steps may 
be straightforwardly adapted to obtain payment from customers using different forms 
of payment. 

In preferred embodiments, tasks relating to customer authentication 
and purchasing are allocated within the network as follows. Each item purchase link 

10 is preferably directed to a portion of the network called the transaction engine. A 
separate transaction engine is preferably located at each merchant site, so that, at any 
time that customers are able to access the merchant Web pages to initiate a purchase 
transaction, a version of the transaction engine is available to conduct the purchase 
transaction. The transaction engine reads and writes network session cookies. In 

15 order to do so, the transaction engines for all of the merchants are preferably 
registered within a single, central domain so that all of the transaction engines at all 
of the merchant sites may read and write the same cookies on the customer computer 
system. When an item purchase link is activated, the transaction engine checks for a 
valid network session cookie on the customer computer system, indicating that the 

20 customer has already been authenticated. If the transaction engine does not find a 
valid network session cookie, the transaction engine redirects processing to a 
customer information subsystem of the network. The customer information 
subsystem portion of the network performs authentication or registration for the 
customer, then instructs the transaction engine to confirm the transaction, generate a 

25 transaction record, write or refresh the network session cookie, and deliver the 
purchased item. To deliver the purchased item, in one embodiment, the transaction 
engine retrieves the data for the item from the merchant, and delivers the data for the 
item to the customer. 

In another embodiment of the invention, in order to avoid the time and 

30 processing cost of relaying the data for the item through the transaction engine, rather 
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than itself retrieving the data for the item, the transaction engine sends a request to the 
merchant computer system, through the customer computer system, to transmit the 
data for the item directly to the user. The request includes a "ticket" — an encrypted 
token attesting to the legitimacy of the request. At the merchant computer system, an 
5 authorization subsystem decrypts and verifies the ticket, creates a merchant session 
cookie that is similar to the network session cookie and that attests to the purchase 
and the authentication of the customer, and transmits the data for the item to the 
customer computer system. 

Locating authorization subsystems at merchant computer systems also 

10 enables the network to manage customer authentication for merchants in their own 
domains. When a customer attempts to access a restricted portion of a merchant's 
Web site that is in a domain other than the central domain of the network, the 
authorization subsystem on the merchant computer system for that merchant checks 
to see whether a valid merchant cookie for that merchant is present on the customer 

15 computer system. Such a merchant cookie, if it is present on the customer computer 
system, attests to the current authentication of the user by the merchant. If a valid 
merchant cookie for that merchant is present on the customer computer system, the 
authorization subsystem allows access to the restricted portion of the merchant's Web 
site. If not, the authorization subsystem contacts the transaction engine. If the 

20 transaction engine finds a valid network session cookie on the customer machine — 
that is, a cookie attesting to the authentication of the customer in the central 
domain — it instructs the authorization subsystem to write a merchant session cookie 
and permit access to the restricted portion in the merchant's domain. 

In a manner similar to the purchase process, if the transaction engine 

25 does not find a network session cookie on the customer machine, the transaction 
engine redirects processing to the customer information subsystem of the network. 
The customer information subsystem portion of the network performs authentication 
or registration for the customer, then instructs the transaction engine to create a 
network session cookie to the customer computer system. The transaction engine 

30 further instructs the authorization subsystem to write a merchant session cookie and 
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permit access to the restricted portion. In this way, the network provides a common 
method for signing onto the Web sites of all of the merchants, even those with 
restricted portions outside of the central network domain. Further, a customer may 
visit restricted areas of several different merchants, and is only required to sign on 
5 once. 

In addition to some or all of the foregoing features, the network 
additionally preferably provides customers with centralized, automated services for 
account management, product refunds, subscription management, and multiple 
purchasing accounts linked to the same payment account. 

10 Figures 21-25 illustrate the automated product refund service 

preferably provided by the network. Figure 21 is a screenshot diagram showing a 
sample customer statement. The statement 2100 contains entries, such as entries 
2110 and 2120, each containing information about an item purchased by the customer 
named "Joe User." For example, entry 2120 in the statement contains information 

15 about the "Electrical Power Systems FX 98" report purchased from "Stat USA." The 
statement further includes the current balance 2130 for this account. 

Each entry includes a link for displaying additional detail about the 
purchased item. For example, entry 2120 includes link 2121, which the user may 
activate to display additional information about the Stat USA report. Figure 22 is a 

20 screenshot diagram showing a sample item information page. The item information 
page 2200 includes information 2210 about the item. This information includes a 
link 22 1 1 that Can be activated to access the purchased item. The item information 
page also includes a button 2220 that can be activated to request a refund for the item. 
A customer may wish to request a refund, for example, if the item was ordered by 

25 mistake, if the item does not conform to the customer's expectations, or if the item 
could not be properly downloaded. 

Figure 23 is a screenshot diagram showing a sample refund request. 
The refund request 2300 is displayed in response to the customer's activation of 
button 2340. The refund request contains information 2310 about the item for which 

30 a refund is sought, a listbox 2320 for specifying a reason for the refund request, and a 
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field 2330 for entering a further explanation of the circumstances surrounding the 
request for refund. The refund request further contains a button 2340 that can be 
activated to submit the refund request. Figure 24 is a screenshot diagram showing a 
sample confirmation screen confirming a refund request. The confirmation screen 
5 2400 is preferably displayed in response to the activation of button 2340. 

After the refund request is submitted, the customer's statement is 
preferably updated to reflect the submission of the refund request: Figure 25 is a 
screenshot diagram showing a sample statement reflecting the submission of a refund 
request. The updated statement 2500 includes a line 2521 indicating that a refund has 
10 been requested for item 2520. Line 2521 further indicates that the price of item 2520, 
$1.00, is being deducted from the account balance while the refund request is being 
considered. As a result, the account balance 2530 is reduced to include only the price 
of item 2510. 

In processing refund requests, the network preferably employs a 
15 maximum automatic refund threshold. If a refund request is directed to an item 
having a price that is less than the maximum automatic refund threshold, the network 
preferably automatically grants the refund request. On the other hand, the network 
applies a more rigorous evaluation process to refund requests that are directed to 
items having prices greater than the maximum automatic refund threshold. The 

20 network preferably forwards such refund requests to a human customer service 
representative. This use of a maximum automatic refund threshold reflects a 
recognition that evaluation by a human customer service representative may incur a 
significant cost that, in many cases, exceeds the cost of granting the refund. In a 
preferred embodiment, the maximum automatic refund threshold is set at $10.00. As 

25 a result, a customer may conveniently complete the submission of a refund request 
without interacting directly with a human customer service representative. Further, in 
most cases, the network relieves its operator of any need to expend customer service 
representative time to process refund requests. 

Figures 26-27 illustrate the automated, centralized subscription 

30 management service preferably provided by the network. Figure 26 is a screenshot 
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diagram showing a sample subscription management page. The subscription 
management page 2600 contains entries, such as entries 2610 and 2620, each 
containing information about a subscription purchased by the customer named "Joe 
User." For example, entry 2610 in the subscription management page contains 
5 information about a subscription to the "Wall Street Journal." Each entry also 
includes an indication of the expiration date of the subscription, as well as an 
indication of whether the subscription will automatically renew when it expires. 

Each entry includes a link for displaying information about or 
modifying the subscription. For example, entry 2610 includes link 2611, which the 

10 user may activate to display additional information about the Wall Street Journal 
subscription. Figure 27 is a screenshot diagram showing a sample subscription 
information page. The subscription information page 2700 includes information 2710 
about the subscription. This information includes a link 271 1 that can be activated to 
access the subscription. The item information page also includes buttons 2721-2723 

15 for modifying the subscription. The user may activate button 2721 to immediately 
renew the subscription for another term. When button 2721 is activated, the network 
updates the subscription management and subscription information pages to extend 
the expiration date of the subscription by the length of a term, and notifies the 
transaction engine at the merchant site to update the status of the subscription. The 

20 user may activate button 2722 to specify that the subscription should automatically 
renew for another term when the present term expires. When button 2722 is activated, 
the network updates the subscription management and subscription information pages 
to indicate that the subscription will automatically renew, and notifies the transaction 
engine at the merchant site to update the status of the subscription. The user may 

25 activate button 2723 to cancel the subscription. When button 2722 is activated, the 
network preferably credits the customer's account for a pro-rated portion of the 
subscription price. The network further updates the subscription management page to 
remove the entry for this subscription, and notifies the transaction engine at the 
merchant site to update the status of the subscription. 
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As a result, a customer may conveniently perform subscription 
management operations without interacting directly with a human customer service 
representative. Further, the network relieves its operator of any need to expend 
customer service representative time to process subscription management operations. 
5 In order to facilitate purchasing by multiple customers who pay for 

purchases together, the network preferably provides a feature in which it associates 
multiple purchasing accounts with a single payment account. This feature enables a 
company to pay for and track the purchases of its employees, a parent to pay for and 
track the purchases of his or her children, or an individual to separate his or her 

10 business purchases from his or her personal purchases. In accordance with this 
feature, a first customer may register as described above, in order to obtain both a 
purchasing account for purchasing items, and a payment account for paying for those 
purchases. At a later time, the first customer may create additional purchasing 
accounts that are "associated" with the payment account, either for others, or for 

15 himself or herself. Any purchases made with an additional purchasing account are 
consumed using the additional purchasing account, and are billed to the associated 
payment account, using the payment information associated with this payment 
account. 

Figures 28-30 illustrate the multiple purchasing accounts feature 
20 preferably provided by the network. In a preferred embodiment, an additional 
purchasing account can be added to an existing payment account by a customer 
signed on to an existing purchasing account associated with the payment account. 
Figure 28 is a screenshot diagram showing a sample registration page for registering 
an additional purchasing account for an existing payment account. In the example, 
25 the registration page shown is used by the customer named "Joe User" to add an 
additional purchasing account for "Jean User" to his existing payment account. The 
registration page contains fields 2810 into which the customer enters information 
about the customer that will use the additional purchasing account, including the 
email address of this customer, and the user name and password to be used with the 
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additional purchasing account. After entering this information, the customer activates 
button 2820 to register the additional purchasing account. 

After the additional purchasing account has been registered, it may be 
used by Jean User to purchase items. Figure 29 is a screenshot diagram showing a 
5 sample customer statement showing purchases made with the additional purchasing 
account. The customer statement 2900 contains entries 2910 and 2920 for items 
purchased by Jean User using her purchasing account. The customer statement 
further contains a total 2930 of the items that Jean User has purchased. It should be 
noted that, in the preferred embodiment shown, items purchased using other 

10 purchasing accounts associated with the same payment account (e.g., those purchased 
by Joe User using his purchase account, shown in Figure 21) are not shown on the 
customer statement or included in the total. 

On the other hand, customers signed on to the payment account (or to 
the first purchasing account, which is preferably more tightly coupled to the payment 

15 account than are additional purchasing accounts) may display the purchases made 
using other customer accounts associated with the same payment account. Figure 30 
is a screenshot diagram showing a sample customer statement showing purchases 
made with multiple purchasing accounts that are each associated with the same 
payment account. The customer statement 3000 includes both entries 3010 and 3020 

20 describing purchases made by Joe User using his purchasing account, and entries 
3030 and 3040 describing purchases made by Jean User using her purchasing 
account. Additionally, the customer statement shows a total 3050 that reflects the 
purchases made by both Joe User and Jean User. It can be seen that this statement 
permits a user of a payment account to review the purchases made using all of the 

25 purchasing accounts associated with the payment account, and to determine the 
amount that will requested in the next payment request generated by the network for 
the payment account. 

While this invention has been shown and described with reference to 
preferred embodiments, it will be understood by those skilled in the art that various 

30 changes or modifications in form and detail may be made without departing from the 
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scope of the invention. For example, instead of operating in conjunction with 
multiple merchants, the network may operate in conjunction with a single merchant. 
Further, the functionalities provided by the network may be allocated differently 
across the described computer systems, or may be provided by a different 
5 combination of computer systems than described. Further, these computer systems 
may be connected by a combination of different networks, instead of by a single 
network such as the Internet. The network may further be reconfigured to more 
optimally perform in particular business environments. Additionally, the network 
may be used to sell goods and services other than digital goods, including physical 
10 goods. Also, the network may preferably accept payment information and generate 
payment requests for any form of payment, or any combination of different forms of 
payment. 



WO 00/33221 

31 



CLAIMS 

We claim: 



1 1. A method in a computer network for managing purchase 

2 transactions for the Web sites of a plurality of merchants using a transaction network, 

3 comprising the steps of: 

4 for each of the plurality of merchant Web sites, under the control of the 

5 merchant Web site: 

6 displaying items available for purchase, each item having a price; 

7 receiving user input from users using Web clients selecting items 

8 for purchase; and 

9 for each item selection, forwarding a purchase request to the 

10 transaction network indicating the price of the selected item; 

1 1 under the control of the transaction network: 

12 receiving transaction network purchase requests forwarded from 

1 3 the plurality of merchant Web sites; 

14 for each received purchase request: 

15 discerning the identity of the user; and 

16 generating a pending transaction record indicating the 

17 identity of the user, the price of the selected item, and the identity of the forwarding 

18 Website; 

19 periodically determining, for each user whose identity is 

20 indicated by a pending transaction record, the sum of the prices of the pending 

2 1 transaction records indicating the identity of the user; 

22 where the determined sum for a user exceeds a billing threshold, 

23 submitting to a payment processor a request for settlement for the determined sum 

24 against an account of the user; 

25 receiving settlement indications from the payment processor each 

26 indicating payment of an identified submitted a request for settlement; 
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27 for each received settlement indication, for each transaction 

28 record whose price is included in the sum of the billing transaction identified by the 

29 received settlement indication: 

30 crediting an account of the merchant identified by the 

3 1 transaction record; and 

32 removing the pending status of the transaction record. 

1 2. A method in one or more computer systems for procuring 

2 payment for purchase transactions each originating with a particular user and vendor, 

3 comprising the steps of: 

4 receiving purchase requests each originating at one of a plurality of 

5 vendor Web sites, each purchase request indicating a purchase price; 

for each received purchase request: 

7 discerning the identity of a user with which the purchase request 

8 originated; and 

9 storing a pending transaction record indicating the identity of the 

10 user, the purchase price, and the identity of the vendor at whose Web site the purchase 

1 1 request originated; 

12 periodically determining, for each user whose identity is indicated by a 

13 pending transaction record, the sum of the prices of the pending transaction records 

14 indicating the identity of the user; 

15 where the determined sum for a user exceeds a billing threshold, 

16 submitting to a payment processor a billing transaction for the determined sum against 

17 an account of the user; 

18 receiving settlement indications from the payment processor each 

19 indicating payment of an identified submitted billing transaction; 

20 for each received settlement indication, for each transaction record 

21 whose price is included in the sum of the billing transaction identified by the received 

22 settlement indication: 
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23 crediting an account of the vendor identified by the 

24 transaction record; and 

25 removing the pending status of the transaction record. 

1 3. One or more computer memories collectively containing a data 

2 structure for purchasing items from different vendors, the data structure comprising: 

3 a first Web page, under the control of a first vendor, containing 

4 information describing a first item and a first link to a purchasing system not under the 

5 control of the first vendor, the first link activatable by users to purchase the first item; 



6 a second Web page, under the control of a second vendor distinct from 

7 the first vendor, containing information describing a second item and a second link to 

8 the purchasing system, the purchasing system also not under the control of the second 

9 vendor, the second link activatable by users to purchase the second item; 

10 instructions stored in a purchasing system, the instructions responding to 

1 1 the activation of the first link by: 

12 identifying the user activating the first link; 

13 establishing an account for the identified user if one has not yet 

14 been established; 

15 causing the purchase of the first item to be posted to the account 

16 of the identified user; and 

17 providing the first item to the identified user, 

18 the instructions responding to the activation of the second link by: 

19 identifying the user activating the second link; 

20 establishing an account for the identified user if one has not yet 

2 1 been established; 

22 causing the purchase of the second item to be posted to the 

23 account of the identified user; and 

24 providing the second item to the identified user. 
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1 4. The computer memories of claim 3 wherein the instructions 

2 stored on the purchasing system are provided in an active server object. 



1 5. A method in a computer system for generating payment requests 

2 incorporating multiple purchase transactions, comprising the steps of: 

3 receiving purchase transaction indications, each purchase transaction 

4 indication indicating an amount and identifying one of a plurality of customers; 

5 for each customer: 

6 periodically determining the sum of the amounts of the received 

7 purchase transaction indications identifying the customer that have not been 

8 incorporated in a payment request; and 

9 when the determined sum exceeds a billing threshold, generating 

10 a new payment request for the customer in the amount of the sum that incorporates the 

1 1 received purchase transaction indications identifying the customer that have not been 

12 incorporated in a payment request. 

1 6. The method of claim 5 wherein the receiving step receives 

2 purchase transaction indications from a number of different vendors often whom the 

3 customers have made purchases. 

1 7. The method of claim 6, further comprising the steps of: 

2 for each vendor, collecting transaction indications indicating transactions 

3 entered into with the vendor; and 

4 retrieving the collected transaction indications from each vendor. 



1 8. The method of claim 5 wherein the generating step generates 

2 settlement requests, and wherein the method further comprises the step of transmitting 

3 generated settlement requests to a payment processor for settlement. 
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1 9. A computer-readable medium whose contents cause a computer 

2 system to generate billing transactions incorporating multiple purchase transactions by 

3 performing the steps of: 

4 receiving purchase transaction indications, each purchase transaction 

5 indication indicating an amount and identifying one of a plurality of customers; and 

6 for each customer: 

7 periodically determining the sum of the amounts of the received 

8 purchase transaction indications identifying the customer that have not been 

9 incorporated in a billing transaction; and 

10 when the determined sum exceeds a billing threshold, generating 

1 1 a new billing transaction for the customer in the amount of the sum that incorporates the 

12 received purchase transaction indications identifying the customer that have not been 
J 3 incorporated in a billing transaction. 

1 10. The computer-readable medium of claim 9 wherein the receiving 

2 step receives purchase transaction indications from a number of different content 

3 providers with whom the customers have entered into purchase transactions. 



1 11. A computer system for generating billing transactions 

2 incorporating multiple purchase transactions, comprising: 

3 a receiver that receives purchase transaction indications, each purchase 

4 transaction indication indicating an amount and identifying one of a plurality of 

5 customers; 

6 an adder that, for each customer, periodically determines the sum of the 

7 amounts of the received purchase transaction indications received by the receiver that 

8 identify the customer that have not been incorporated in a billing transaction; and 

9 a billing transaction generator that, when the sum determined by the 

10 adder exceeds a billing threshold, generates a new billing transaction for the customer in 
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the amount of the sum that incorporates the received purchase transaction indications 
identifying the customer that have not been incorporated in a billing transaction. 

12. A method in a computer system for aggregating charge 
transactions entered into by a customer, the method comprising the steps of: 

over time, receiving a stream of charge transactions entered into by the 
customer, each charge transaction having an amount; 

identifying a time at which the sum of the amounts of the received 
charge transactions exceeds a threshold amount; and 

submitting to a payment processor a payment request for the sum of the 
received charge transactions. 

13. The method of claim 12 wherein one of the received charge 
transactions was entered into in conjunction with a third-party vendor, further 
comprising the steps of: 

receiving from the payment processor, in response to the submitting step, 
a settlement indication indicating payment of the submitted payment request; and 

in response to the step of receiving a settlement indication, crediting to 
the vendor a portion of the sum. 



14. A computer-readable medium whose contents cause a computer 
system to process charge transactions entered into by a customer by performing the 
steps of: 

receiving a stream of charge transactions entered into by the customer, 
each charge transaction having an amount; 

identifying a time at which the sum of the amounts of the received 
charge transactions exceeds a threshold amount; and 

submitting to a payment processor a settlement request for the sum of the 
received charge transactions. 
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1 15. The computer-readable medium of claim 14 wherein one of the 

2 received charge transactions was entered into in conjunction with a third-party vendor, 

3 and wherein the contents of the computer-readable medium further cause the computer 

4 system to perform the steps of: 

5 receiving from the payment processor, in response to the submitting step, 

6 a payment indication indicating payment of the submitted settlement request; and 

7 in response to the receiving step, crediting to the vendor a portion of the 

8 sum. 

I 16. A computer memory device storing a charge aggregation data 



2 structure for storing information about charge transactions directed to a particular form 

3 of payment, the form of payment having a minimum threshold for charges against the 

4 form of payment, the data structure comprising a plurality of records each representing 

5 a distinct charge transaction, each record indicating an amount for the transaction it 

6 represents, at least some of the records indicating amounts below the minimum 

7 threshold for the form of payment, 

8 such that the data structure may be accessed to combine a plurality of the charge 

9 transactions into a single aggregate transaction having an amount corresponding to the 

10 combined amounts indicated by the records that is in excess of the minimum threshold, 

1 1 such that the aggregate transaction may be charged against the form of payment. 



1 17. The computer memory device of claim 16 wherein the form of 

2 payment is a credit card. 

1 18. The computer memory device of claim 16 wherein the form of 

2 payment is a debit card. 

1 19. The computer memory device of claim 16 wherein the form of 

2 payment is an automated clearing house payment. 
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! 20. The computer memory device of claim 16 wherein the form of 

2 payment is an electronic funds transfer transaction. 

1 21. The computer memory device of claim 16 wherein the form of 

2 the payment is a purchase order. 

I 22. The computer memory device of claim 16 wherein each record of 



2 the data structures identifies one of a plurality of customers as having entered into the 

3 transaction represented by the record, 

4 such that the data structure may be accessed to combine a plurality of the charge 

5 transactions into a plurality single aggregate transactions each corresponding to a single 

6 customer. 



1 23. A memory device storing an aggregate charge data structure, the 

2 aggregate charge data structure being suitable for submission to a payment processor for 

3 payment, the data structure comprising: 

4 a consumer identifier identifying a consumer that has charged a 

5 multiplicity of purchase transactions, each purchase transaction having an amount; and 

6 an aggregate charged amount constituting the sum of the amounts of a 



7 constituent plurality of the multiplicity of purchase transactions charged by the 

8 consumer, at least one of the amounts of the constituent purchase transactions falling 

9 below a minimum threshold for submitting charges to a payment processor for payment, 

10 such that the data structure may be submitted to a payment processor for payment in 

1 1 place of the constituent purchase transactions. 

1 24. The memory device of claim 23 wherein the data structure further 

2 comprises both a consumer identifier and aggregate charged amount for each of a 

3 plurality of additional consumers. 
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1 25. A method in a computer system for identifying a user using a 

2 user computer system among a group of users, the method using a potentially non- 

3 unique member identifier, the method comprising the steps of: 

4 (a) registering the user by: 

5 (1) obtaining for the user a member identifier that is potentially 

6 not unique; 

7 (2) after obtaining the solicited member identifier in step (a)(1), 

8 storing a unique identifier for the user on the user computer system in conjunction with 

9 the obtained member identifier; and 

10 (b) identifying the user by: 

11 (1) soliciting from the user the member identifier of the user; 

12 (2) receiving from the user, in response to step (b)(1), the 

13 member identifier of the user; 

14 (3) reading from the user computer system the unique identifier 

15 stored in conjunction with the member identifier received in step (b)(2); 

16 (4) identifying the user using the unique identifier read in step 

17 (b)(3). 

1 26. The method of claim 25 wherein a plurality of users having the 

2 same user computer system are registered by repeating steps (a)(l )-(a)(2) for each of the 

3 plurality of users. 

1 27. The method of claim 25 wherein obtaining step (a)(1) comprises 

2 the steps of: 

3 soliciting from the user a member identifier of the user; and 

4 receiving from the user a member identifier of the user. 

1 28. The method of claim 25 wherein the method is practiced on 

2 behalf of a first online service, and wherein obtaining step (a)(1) comprises the step of 
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3 obtaining for the user a member identifier used by the user to identify himself or herself 

4 to second online service distinct from the first online service. 

1 29. The method of claim 28 wherein the step of obtaining for the user 

2 a member identifier used by the user to identify himself or herself to second online 

3 service obtains the member identifier from an operator of the second online service. 



1 30. A method in one or more computer systems for purchasing 

2 products offered for sale by multiple vendors, comprising the steps of: 

3 receiving a single, contiguous set of user interface interactions for 

4 establishing the identity of the user; 

5 establishing the identity of the user based on the single, contiguous set of 

6 user interface interactions received in the receiving step; 

7 purchasing an item offered for sale by a first vendor based on the user 

8 identity established in the establishing step; and 

9 purchasing an item offered for sale by a second vendor distinct from the 
10 first vendor based on the user identity established in the establishing step. 

1 31. The method of claim 30, further comprising the steps of: 

2 in conjunction with the step of purchasing an item offered for sale by a 

3 first vendor, displaying a visual indication of the first vendor; and 

4 in conjunction with the steps of purchasing an item offered for sale by a 

5 second vendor, displaying a visual indication of the second vendor. 

6 32. The method of claim 30 wherein the receiving and establishing 

7 steps are performed as part of the step of purchasing an item offered for sale by the first 

8 vendor. 

1 33. The method of claim 30 wherein the second vendor has a 



2 computer system, and wherein the establishing step includes the step of storing a central 
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3 state signifying the establishment of the identity of the user, and wherein the step of 

4 purchasing an item offered for sale by the second vendor include the steps of: 

5 checking the stored state; 

6 in response to checking the stored state, sending an encoded ticket to the 

7 second computer system; 

8 under the control of the second computer system: 

9 decoding the encoded ticket; 

10 validating the decoded ticket; and 

1 1 performing the step of purchasing an item offered for sale by the 

12 second vendor in response to the validating step. 

1 34. The method of claim 30 wherein the establishing step includes 

2 the step of storing a central state signifying the establishment of the identity of the user, 

3 and wherein the step of purchasing an item offered for sale by a second vendor include 

4 the steps of: 

5 checking the stored central state; and 

6 performing the step of purchasing an item offered for sale by a second 

7 vendor in response to the checking step. 

1 35. A method in one or more computer systems for accessing 

2 multiple access-restricted Web sites, comprising the steps of: 

3 receiving a single, contiguous set of user interface interactions for 

4 establishing the identity of the user; 

5 establishing the identity of the user based on the single, contiguous set of 

6 user interface interactions received in the receiving step; 

7 granting access to a first access-restricted Web site based on the user 

8 identity established in the establishing step; and 

9 granting access to a second access-restricted Web site distinct from the 

10 second access-restricted Web site based on the user identity established in the 

1 1 establishing step. 
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1 36. The method of claim 35, wherein the second access-restricted 

2 Web site is served by a second computer system, and wherein the establishing step 

3 includes the step of storing a state signifying the establishment of the identity of the 

4 user, and wherein the step of granting access to the second access-restricted Web site 

5 include the steps of: 

6 checking the stored state; 

7 in response to checking the stored state, sending an encoded ticket to the 

8 second computer system; 

9 under the control of the second computer system: 

1 0 decoding the encoded ticket; 

1 1 validating the decoded ticket; and 

12 performing the step of granting access to the second access- 

13 restricted Web site in response to the validating step. 

1 37. The method of claim 35 wherein the establishing step includes 

2 the step of storing a central state signifying the establishment of the identity of the user, 

3 and wherein the step of granting access to the second access-restricted Web site include 

4 the steps of: 

5 checking the stored central state; and 

6 performing the step of granting access to the second access-restricted 

7 Web site in response to the checking step. 

1 38. A transaction network for vending digital content from a plurality 

2 of merchants comprising: 

3 for each merchant, a transaction engine for conducting transactions with 

4 customers to purchase digital content and deliver purchased digital content; and 

5 a network service center for collecting indicia of transactions entered 

6 into with each merchant and submitting payment requests for the collected transactions 

7 to a payment processor. 
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1 39. The transaction network of claim 38 wherein the network service 

2 center aggregates the transactions conducted with each customer, and wherein the 

3 payment requests are submitted for the aggregated transactions. 

I 40. The transaction network of 39 wherein the network service center 



2 further receives from the payment processor indications of the payment of the submitted 

3 payment requests, and, for each received indication, credits the merchants with which 

4 the transactions aggregated into the request where conducted. 



1 41. A method in one or more computer systems for providing to a 

2 customer automatic refund support for a purchase transaction, the method comprising: 

3 generating for the customer a display soliciting information supporting a 

4 request for refund of the purchase transaction; 

5 receiving from the customer, in response to the generated display, 

6 information supporting a request for refund; and 

7 automatically generating a request for refund incorporating the received 

8 information, 

9 such that the customer requests a refund of the purchase transaction without additional 
10 interaction. 

1 42. The method of claim 41 , further comprising the steps of: 

2 generating for the customer a display containing indicators of each of a 

3 plurality of transactions entered into by the customer, at least two of the plurality of 

4 transaction being entered into with different merchants; and 

5 receiving from the customer a selection of the transaction indication of a 

6 selected transaction, 

7 and wherein the step of generating a display soliciting information to support a request 

8 for refund of a service transaction generates a display soliciting information to support a 

9 request for refund of the selected transaction. 
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1 43. The method of claim 41 wherein the transaction has an amount, 

2 the method further comprising the steps of: 

3 determining whether the amount of the transaction is less than a 

4 maximum threshold; and 

5 if the amount of the transaction is less than the maximum threshold, 

6 automatically granting the requests for refund. 

1 44. The method of claim 43, further comprising the step of, if the 

2 amount of the transaction is not less than the maximum threshold, determining whether 

3 to grant the request for refund based upon the information supporting the request for 

4 refund. 

1 45. A method in one or more computer systems for enabling a 

2 subscriber to manage content subscriptions from a plurality of content sources, the 

3 method comprising: 

4 displaying for the subscriber an indication of each of a plurality of 

5 content subscriptions entered into by the subscriber, at least two of the content 

6 subscriptions being with different content sources; 

7 receiving from the subscriber a selection of the indication of a selected 

8 content subscription; and 

9 on behalf of the subscriber, performing a subscription management 

10 operation with respect to the selected content subscription. 

1 46. The method of claim 45 wherein the performing step cancels the 

2 selected content subscription. 

1 47. The method of claim 45 wherein the performing step renews the 

2 selected content subscription. 
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1 48. A method in one or more computer systems for providing a 

2 plurality of purchasing accounts for purchasing digital content, all of the purchasing 

3 accounts of the plurality being associated with a single payment account, the method 

4 comprising: 

5 storing payment information for the payment account that is usable to 

6 procure payment for digital content purchases made using any of the plurality of 

7 purchasing accounts; 

8 storing for each of the purchasing accounts a different account identifier; 

9 in response to each purchase request specifying content received in 

10 connection with the account identifier of one of the purchasing accounts: 

1 1 completing a purchase of the specified content, and 

12 providing the specified content; and 

13 utilizing the payment information stored for the payment account to 

14 procure payment for digital content purchases completed using any of the plurality of 

15 purchasing accounts. 

1 49. The method of claim 48, further comprising the steps of: 

2 storing an account identifier for the payment account; and 

3 in response to a request received in connection with the account 

4 identifier for the payment account, displaying information describing the purchases 

5 completed using any of the plurality of purchasing accounts. 

1 50. The method of claim 48, further comprising the step of, in 

2 response to a request received in connection with the account identifier for a selected 

3 one of the purchasing accounts, displaying information describing the purchases made 

4 completed using only the selected purchasing account. 
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ELECTRONIC COMMERCE USING A TRANSACTION NETWORK 

TECHNICAL FIELD 

The present invention is directed to the field of electronic commerce, 
and more particularly, to the field of facilitating user registration and authentication, 
5 purchasing from multiple merchants, aggregating payment transactions, and merchant 
remittance for electronic commerce transactions, such as those conducted on the 
Internet. 

BACKGROUND OF THE INVENTION 

The World Wide Web ("the Web") is an interactive computer 

10 environment. The Web uses a collection of common protocols, including the 
Hypertext Transfer Protocol ("HTTP"), and file formats, including Hypertext Markup 
Language ("HTML"), to enable users to obtain information from or exchange 
information with a huge number of organizations, via the Internet, from virtually 
anywhere in the world. In order to establish a presence on the Web, organizations 

15 generally construct a "Web site." Such a Web site generally includes a collection of 
documents relating to the organization that is accessible by users using an address on 
the Web, called a Universal Resource Locator ("URL"), publicized by the 
organization. 

The Web is increasingly used as a channel for commercial activity. 

20 Many organizations have achieved great success at selling products and services 
through their Web sites. For instance, a significant fraction of the airline tickets, 
music compact discs, and books sold today are sold via the Web. 

In order to attract customers for such sales, a merchant must generally 
advertise its Web site on the Web or another more traditional media, or otherwise pay 

25 to attract customers. In most such sales, the purchase price is paid using a credit card 
or check card. In order to complete such a purchase, the customer provides to the 
merchant information associated with the credit card or check card, such as the 
number and expiration date of the credit card or check card. The customer commonly 
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also provides additional information about himself or herself, such as name and postal 
address for delivering physical goods. 

The merchant uses the provided credit card or debit card information 
to generate a request for payment of the purchase price, which it transmits to a 
5 payment processor. The payment processor in turn charges the purchase price to the 
customer's credit card or check card, and credits the merchant's account in the 
amount of the purchase price. For a particular customer, this process is generally 
repeated for each merchant from which the customer makes a purchase. Similarly, a 
merchant generally repeats this process for each purchase made by a customer. 
10 The foregoing approach is efficient for purchases having a significant 

purchase price, such as those above US$ 20. However, because a significant portion 
of the actual costs of processing a credit card or check card transaction are fixed and 
not related to the amount of the transaction, processing credit card transactions for 
lower amounts is generally cost-prohibitive. As a result, credit card and check card 

15 transactions are generally not used to purchase goods and services having a relatively 
low price, such as those below US$ 20. Additionally, the high cost of providing 
customer service on the Internet, including such recurring operations as supplying 
lost passwords, raises the cost for selling goods, thus raising the minimum price at 
which goods must be sold to realize a profit. 

20 While other forms of payment, such as cash proxies, have been 

proposed for use in such lower-priced transactions, these other forms of payment 
have failed to achieve acceptance on the Web. This is largely due to the amount of 
extra interaction that these cash proxy payment methods require from the customer, 
as customers are often unwilling to tolerate a great deal of inconvenience to purchase 

25 an inexpensive item. Moreover, even if such an alternative form of payment did 
achieve acceptance on the Web, they typically impose significant processing costs on 
those merchants that accept them, and do nothing to alleviate customer service costs. 

Since credit card and check card transactions are the only forms of 
payment that have achieved general acceptance on the Web, it is generally not 

30 possible to buy such lower-priced goods and services on the Web. These lower- 
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priced purchases are, however, important. In particular, digital goods, such as 
electronic magazine articles, music, or games, delivered via the Web have a very 
small marginal cost. While there may be a significant demand for some digital goods 
if priced at appropriately modest levels, when their price is set at or above the 
5 minimum viability threshold for credit card and check card transactions, demand is 
very low or nonexistent. Therefore, because goods cannot be sold via credit card or 
check card at a price below the minimum viability threshold, and there is little 
demand at or above the minimum viability threshold, such goods are incapable of 
generating significant revenue and generally are not offered for sale. 

10 The transactional model discussed above, in which customers make 

purchases directly from merchants using credit card or check card transactions, have 
serious disadvantages for both customers and merchants. First, as noted above, low- 
priced purchases are generally impossible to conduct using this model, which 
generally precludes customers from purchasing and merchants from selling certain 

15 products, and limits the number of customers that can purchase others. Further, the 
model requires each customer to expend significant effort managing his or her 
relationship with each merchant, and also requires each merchant to make significant 
up-front and continuing investments in managing its relationship with its customers 
and with its payment processor. 

20 Figure 1 is a relationship diagram showing the relationships arising 

between customers, merchants, and payment processors in accordance with the 
conventional transaction model. The diagram shows a number of customers 110, 
who engage in purchase transactions with a number of merchants 120. Each line 
between a customer 110 and a merchant 120 represents a relationship between the 

25 customer and the merchant that must be managed by both the customer and the 
merchant. 

From the customer's perspective, he or she must provide credit card or 
check card payment information to each new merchant from which the customer 
makes a purchase. To do so is generally both inconvenient, because the customer 
30 must enter the same information over and over, and disconcerting, because the 
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customer is required to entrust this sensitive information to several different parties, 
one or more of which may be untrustworthy. In addition, customers must learn the 
customer service policies of every merchant from which they purchase, which can be 
a burdensome process, especially for modestly-priced purchases. 
5 From the merchant's perspective, it must build, operate, and scale up 

an infrastructure for accepting credit or check card payments from customers, for 
delivering purchased goods, and for providing customer service to those customers. 
Such infrastructures are generally expensive, and often distract merchants from their 
more fundamental role of creating and selling products. 

10 Further disadvantages arise in the conventional model when a 

merchant subjects customers to user authentication. Merchants often use user 
authentication, the process of establishing that a Web user is actually a returning 
customer, to enable customers to make subsequent purchases using the payment 
information from a previous purchase, or to facilitate continuing consumption of 

15 purchased goods, such as continued access to an online periodical to which the 
customer has purchased a subscription. Generally, in order to authenticate as a 
returning customer, a user must enter a user name and password that is specific to 
each merchant. From the customer's perspective, submitting to user authentication 
involves the disadvantages of having to use a user name that is unique among those of 

20 each merchant's customers and thus is not always freely chosen by the customer, 
having to remember or record each of these different member names, and having to 
re-authenticate each time the customers move from the Web site of one merchant to 
the Web site of another, which can prove burdensome and frustrating for users. 

From the merchant's perspective, performing user authentication 

25 involves the disadvantages of having to build, operate, and scale up a mechanism for 
performing user authentication and a customer database to support user 
authentication, an effort that is potentially both costly and distracting. In addition to 
relationships with its customers, in the conventional model a merchant must also 
maintain a relationship with a payment processor 130 to process credit or check card 

30 transactions. Maintaining a relationship with a payment processor requires the 
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merchant to shop for and negotiate a contract with a payment processor, and to build, 
operate, and scale up a mechanism for communicating with the payment processor, 
another effort that is potentially both costly and distracting. 

It can be seen from the foregoing that, from the perspective of 
5 merchants, a reliable system for selling goods, including lower-priced goods on the 
Web, without having to develop an infrastructure for accepting payment, for 
registering and authenticating customers would have significant utility, or for 
providing customer support. It can further be seen that, from the perspective of 
customers, a convenient system that facilitates the purchase of goods, including 
10 lower-priced goods from a number of different merchants without having to submit 
payment information to each merchant or reauthenticate to each merchant, and which 
provides centralized customer service for purchases made from multiple merchants 
would also have significant utility. 



SUMMARY OF THE INVENTION 

1 5 The present invention provides a new type of transaction network ("the 

network") for facilitating purchase transactions between any number of customers 
and any number of merchants participating in the network. The network is well- 
suited to the purchase of low-priced "digital goods," as well as the purchase of other 
products and services, especially those having relatively low prices, and enables 

20 customer to use traditional forms of payment, such as credit cards. The network 
relieves merchants of the burdens of each maintaining a separate infrastructure for 
authenticating and accepting payment from customers, delivering goods, and 
providing customer service. The network further provides a single registration 
process during which the customer provides credit card payment information once for 

25 all of the merchants, as well as universal authentication to the Web sites of all of the 
merchants through a single user interaction. The network yet further facilitates the 
migration of large existing groups of users from other authentication systems, such as 
those of merchants, to the authentication system provided by the network. The 
network additionally preferably provides customers with centralized, automated 
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services for customer account management, product refunds, subscription 
management, and multiple purchasing accounts linked to the same payment account. 

Figure 2 is a relationship diagram showing the relationships defined 
for customers and merchants by the network. It can be seen that each customer 210, 
5 rather than maintaining a separate purchasing relationship with each merchant 220, 
need only maintain a single purchasing relationship with the network 240. This 
means that the customer need only provide payment information and to register and 
authenticate to the network, not to each merchant. Similarly, each merchant 220, 
rather than maintaining a relationship with each customer 210, need only maintain a 

10 single relationship to the network. This means that, rather than providing 
infrastructure for accepting payment from customers, delivering goods to customers, 
registering and authenticating customers, and providing customer service, the 
merchants may rely upon corresponding functionalities of the network. Further, 
rather than themselves maintaining a relationship with a charge processor 230, the 

15 merchants 220 can rely on the relationship with the charge processor maintained by 
the network 240. Participation in the network thus frees both customers and 
merchants of the substantial burdens of the conventional transaction model described 
above. 

In accordance with the present invention, a new customer may visit the 
20 Web site of any merchant. When the user selects, on the merchant's Web site, a 
product or service (hereafter "item") for purchase, the network determines whether 
the customer is presently registered and authenticated with the network. If the 
customer is not presently registered, the network enables the customer to register with 
the network by providing identity and payment information. The identity information 
25 provided by the customer preferably includes a member identifier and a password for 
use with the network, as well as an electronic mail ("email") address. The payment 
information preferably includes a credit card number, or other information usable to 
charge the customer for purchases. As part of registration process, the network 
preferably verifies the provided payment information. At the conclusion of 
30 registration process, the registered customer is permitted to purchase the item. As a 
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result of the purchase, the purchased item is provided to the customer, and a 
transaction record is created that identifies the customer, the merchant, and the 
amount of the purchase. The visual user interfaces for these registration and purchase 
processes are preferably cobranded with the trademarks of the merchant and the 
5 operator of the network, to indicate that both parties are collaborating in providing the 
purchasing experience enjoyed by the customer. 

After the customer has registered, the customer is effectively signed on 
to the network for a period of time, such as several hours. After registering, the 
customer may again sign on to the network by identifying, "or authenticating," 
10 himself or herself to the network by entering the member identifier and password. 
During the time that the customer is signed on, the customer may browse and 
purchase items from any Web site in the network without repeating the authentication 
process. 

The network periodically reviews the unbilled purchase transaction 
15 records of each customer resulting from purchases made by the customer at any site. 
When the amounts of these records exceed a threshold value, preferably determined 
based upon the amount at which the transaction costs for the form of payment 
provided by the customer become reasonable, the network generates a payment 
request requesting payment of the total amount. The network then combines the 
20 payment requests generated for a number of users and transmits them to a payment 
processor for payment. The payment processor returns a settlement indication for 
each payment request indicating that the payment request has been settled or 
declined. 

At this point, the merchants from whom the customer purchased the 
25 items are each credited with a portion of the corresponding purchase price, and the 
purchase transaction records represented by the payment request are marked as paid. 
In this manner, the network efficiently facilitates purchase transactions having 
relatively low purchase amounts using traditional forms of payment. The network 
further facilitates purchases having relatively low prices by providing centralized 
30 services for seeking refunds and managing subscriptions, and by providing multiple 
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purchasing accounts linked to a single payment account. By providing these 
customer service functionalities to merchants, the network substantially lowers 
merchants' transaction processing costs, thereby enabling merchants to offer for sale 
modestly-priced goods. 
5 In a further embodiment, during registration, the network permits the 

customer to provide a member identifier that is not unique among all of the customers 
of the network. In this embodiment, the network stores a unique identifier for the 
customer, along with the member identifier specified by the customer, in a cookie on 
the customer's computer system. When the customer subsequently authenticates by 

10 providing the member identifier, the network uses the member identifier to find the 
unique identifier on the customer's computer system, and uses the member identifier 
together with the unique identifier to authenticate the customer. In this way, the 
network allows customers to use non-unique member identifiers. This improves the 
customer experience for all customers, as it enables them to choose a particular 

15 member identifier without regard for its use by other customers. This is especially 
valuable where the network has a large number of customers. Facilitating non-unique 
member identifiers also permits the operator of the network to "absorb" or "import" 
existing groups of customers from other online services, where they already have 
member identifiers to which they are accustomed, and which may be redundant with 
20 the member identifiers of other customers of the network. 



BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 is a relationship diagram showing the relationships arising 
between customers, merchants, and payment processors in accordance with the 
conventional transaction model. 
25 Figure 2 is a relationship diagram showing the relationships defined 

for customers and merchants by the network. 

Figure 3 is a high-level block diagram of the computer network 
environment in which the transaction network preferably operates. 
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Figure 4 is a high-level block diagram of a typical merchant computer 

system. 

Figure 5 is a high-level block diagram of a typical customer computer 

system. 

5 Figure 6 is a high-level block diagram of a typical network service 

center computer system. 

Figure 7 is a screen shot diagram showing a Web page displayed by a 

merchant. 

Figure 8 is a flow diagram showing the steps preferably performed by 
10 the network as part of the purchasing process. 

Figure 9 is a flow diagram showing the steps preferably performed by 
the network in order to authenticate a customer. 

Figure 10 is a screenshot diagram showing the sign on dialog 
preferably displayed by the network to collect the member identifier and password. 
15 Figure 1 1 is a flow diagram showing the steps preferably performed by 

the network in order to register the customer with the network. 

Figure 12 is a screenshot diagram showing a registration dialog 1200, 
into which the user enters personal and payment information. 

Figure 13 is a screenshot diagram showing a confirmation dialog 
20 preferably displayed by the network in step 808. 

Figure 14 is a screenshot diagram showing provision of a purchased 

item. 

Figure 1 5 is a screenshot diagram showing a Web page of a second 

merchant. 

25 Figure 16 is a screenshot diagram showing the confirmation dialog 

displayed in response to the customer's selection of link 1524. 

Figure 17 is a screenshot diagram showing the provision of the 
additional purchased item. 

Figure 18 is a table diagram showing the transaction database 
30 maintained by the network. 
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Figure 19 is a flow diagram of the steps preferably performed by the 
network in order to aggregate the transaction records in the transaction database into 
authorizations sent to a payment processor. 

Figure 20 is a flow diagram showing the steps preferably performed by 
5 the network in order to process a settlement report. 

Figure 21 is a screenshot diagram showing a sample customer 

statement. 

Figure 22 is a screenshot diagram showing a sample item information 

page. 

10 Figure 23 is a screenshot diagram showing a sample refund request. 

Figure 24 is a screenshot diagram showing a sample confirmation 
screen confirming a refiind request. 

Figure 25 is a screenshot diagram showing a sample statement 
reflecting the submission of a refund request. 
15 Figure 26 is a screenshot diagram showing a sample subscription 

management page. 

Figure 27 is a screenshot diagram showing a sample subscription 
information page. 

Figure 28 is a screenshot diagram showing a sample registration page 
20 for registering an additional purchasing account for an existing payment account. 

Figure 29 is a screenshot diagram showing a sample customer 
statement showing purchases made with the additional purchasing account. 

Figure 30 is a screenshot diagram showing a sample customer 
statement showing purchases made with multiple purchasing accounts that are each 
25 associated with the same payment account. 

DETAILED DESCRIPTION OF THE INVENTION 

The present invention provides a new type of transaction network ("the 
network") for facilitating purchase transactions between any number of customers 
and any number of merchants participating in the network. The network is well- 
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suited to the purchase of low-priced "digital goods," as well as the purchase of other 
products and services, especially those having relatively low prices, and enables 
customer to use traditional forms of payment, such as credit cards. The network 
relieves merchants of the burdens of each maintaining a separate infrastructure for 
5 authenticating and accepting payment from customers, delivering goods, and 
providing customer service. The network further provides a single registration 
process during which the customer provides credit card payment information once for 
all of the merchants, as well as universal authentication to the Web sites of all of the 
merchants through a single user interaction. The network yet further facilitates the 
3 " 10 migration of large existing groups of users from other authentication systems, such as 
those of merchants, to the authentication system provided by the network. The 
network additionally preferably provides customers with centralized, automated 
services for customer account management, product refunds, subscription 
management, and multiple purchasing accounts linked to the same payment account. 

15 Figure 2 is a relationship diagram showing the relationships defined 

for customers and merchants by the network. It can be seen that each customer 210, 
rather than maintaining a separate purchasing relationship with each merchant 220, 
need only maintain a single purchasing relationship with the network 240. This 
means that the customer need only provide payment information to register and 

20 authenticate the network, not to each merchant. Similarly, each merchant 220, rather 
than maintaining a relationship with each customer 210, need only maintain a single 
relationship to the network. This means that, rather than providing infrastructure for 
accepting payment from customers, delivering goods to customers, registering and 
authenticating customers, and providing customer service, the merchants may relay 

25 upon corresponding functionalities of the network. Further, rather than themselves 
maintaining a relationship with a charge processor 230, the merchants 220 can rely on 
the relationship with the charge processor maintained by the network 240. 
Participation in the network thus frees both customers and merchants of the 
substantial burdens of the conventional transaction model described above. 
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In accordance with the present invention, a new customer may visit the 
Web site of any merchant. When the user selects, on the merchant's Web site, a 
product or service (hereafter "item") for purchase, the network determines whether 
the customer is presently registered and authenticated with the network. If the 
5 customer is not presently registered, the network enables the customer to register with 
the network by providing identity and payment information. The identity information 
provided by the customer preferably includes a member identifier and a password for 
use with the network, as well as an electronic mail ( ik email") address. The payment 
information preferably includes a credit card number, or other information usable to 
10 charge the customer for purchases. As part of registration process, the network 
preferably verifies the provided payment information. At the conclusion of 
registration process, the registered customer is permitted to purchase the item. As a 
result of the purchase, the purchased item is provided to the customer, and a 
transaction record is created that identifies the customer, the merchant, and the 

15 amount of the purchase. The visual user interfaces for these registration and purchase 
processes are preferably cobranded with the trademarks of the merchant and the 
operator of the network, to indicate that both parties are collaborating in providing the 
purchasing experience enjoyed by the user. 

After the customer has registered, the customer is effectively signed 

20 on to the network for a period of time, such as several hours. After registering, the 
customer may again sign on to the network by identifying, "or authenticating," 
himself or herself to the network by entering the member identifier and password. 
During this time that the customer is signed on, the customer may browse and 
purchase items from any Web site in the network without repeating the authentication 

25 process. 

The network periodically reviews the unbilled purchase transaction 
records of each customer resulting from purchases made by the customer at any site. 
When the amounts of these records exceed a threshold value, preferably determined 
based upon the amount at which the transaction costs for the form of payment 
30 provided by the customer become reasonable, the network generates a payment 
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request requesting payment of the total amount. The network then combines the 
payment requests generated for a number of users and transmits them to a payment 
processor for payment. The payment processor returns a settlement indication for 
each payment request indicating that the payment request has been settled or 
5 declined. 

At this point, the merchants from whom the customer purchased the 
items are each credited with a portion of the corresponding purchase price, and the 
purchase transaction records represented by the payment request are marked as paid. 
In this manner, the network efficiently facilitates purchase transactions having 

10 relatively low purchase amounts using traditional forms of payment. The network 
further facilitates purchases having relatively low prices by providing centralized 
services for seeking refunds and managing subscriptions, and by providing multiple 
purchasing accounts linked to a single payment account. By providing these 
customer service functionalities to merchants, the network lowers their transaction 

15 processing cost substantially, thereby enabling merchants to offer for sale modestly- 
priced goods. 

In a further embodiment, during registration, the network permits the 
customer to provide a member identifier that is not unique among all of the customers 
of the network. In this embodiment, the network stores a unique identifier for the 

20 customer, along with the member identifier specified by the customer, in a cookie on 
the customer's computer system. When the customer subsequently authenticates by 
providing the member identifier, the network uses the member identifier to find the 
unique identifier on the customer's computer system, and uses the member identifier 
together with the unique identifier to authenticate the customer. In this way, the 

25 network allows customers to use non-unique member identifiers. This improves the 
customer experience for all customers, as it enables them to choose a particular 
member identifier without regard for its use by other customers. This is especially 
valuable where the network has a large number of customers. Facilitating non-unique 
member identifiers also permits the operator of the network to "absorb" or "import" 

30 existing groups of customers from other online services, where they already have 
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member identifiers to which they are accustomed, and which may be redundant with 
the member identifiers of other customers of the network. 

Figure 3 is a high-level block diagram of the computer network 
environment in which the transaction network preferably operates. Merchant 
5 computer systems 310 are computer systems operated by or on behalf of merchants 
that make items available for purchase by customers of the network. Merchant 
computer systems 310 preferably each provide a Web server that serves Web pages, 
some of which offer items for sale. The merchant computer systems 310 are 
connected to customer computer systems 330 via a network 320, such as the Internet. 

10 The customer computer systems 330 are usable by customers to browse the Web 
pages served by the merchant computer systems 310. When doing such browsing, a 
customer may use a customer computer system 330 to purchase an item offered for 
sale. Such purchase is communicated over the network 320 to a network service 
center computer system, which makes a record of the transaction. The network 

15 service center computer system 340 periodically collects together transactions entered 
into by each user, aggregates them into requests for payment, and forwards these 
payment requests over a secure network 350 to a payment processor computer system 
360 for payment. The configurations of several of the computer systems shown in 
Figure 3 are discussed below in conjunction with Figures 4-6. While the network is 

20 preferably implemented on computer systems configured in this manner, those skilled 
in the art will recognize that the network may be advantageously implemented on 
combinations of computer systems other than those shown in these figures. 

Figure 4 is a high-level block diagram of a typical merchant computer 
system. The merchant computer system 310 includes one or more central processing 

25 units ("CPUs") 410, and a network connection 420 for connecting to the network 320. 
The merchant computer system further comprises computer storage 430, which may 
include both transient storage devices, such as random access memory, and persistent 
storage devices, such as hard drives. The storage preferably includes an HTTP server 
program 431 for serving Web pages 432 offering items for sale. The storage 

30 preferably also includes: a product database 433 for storing items offered for sale; a 
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transaction engine 434 provided by the operator of the network to conduct the sale 
and delivery of items to authenticated customers and an authorization subsystem 
program 435, provided by the operator of the network to manage authorization of 
customers to the merchant Web site. The merchant computer system further includes 
5 a computer-readable media drive 440, which can be used to install software products, 
including the network, which are provided on a removable computer-readable 
medium, such as a CD-ROM or a DVD. 

Figure 5 is a high-level block diagram of a typical customer computer 
system. The customer computer system 330 has one or more CPUs 510 and a 

10 network connection 520. The customer computer system further has a visual display 
530, such as a video monitor for displaying Web pages, a keyboard 540 for inputting 
text, and a pointing device 550, such as a mouse, for selecting positions on the 
display. The customer computer system further includes transient and/or persistent 
storage 560 containing a Web browser program 561 for displaying and interacting 

15 with Web pages, and a cookie file 562 containing information stored on the customer 
computer system by Web servers and/or the network. 

Figure 6 is a high-level block diagram of a typical network service 
center computer system. The network service center computer system 340 has one or 
more CPUs 610, a network connection 620, and a computer readable media drive 

20 630. The network service center computer system further includes transient and/or 
persistent storage 640 containing network service center software 641 for managing 
the record keeping associated with purchase transactions, an HTTP server 642 for 
serving Web pages, a customer database 643 for maintaining information on each 
customer of the network, a merchant database 644 for maintaining information about 

25 each merchant, and a transaction database 645 for maintaining information about 
transactions entered into between customers and merchants. While these tables, 
described in greater detail below, are each conceptually single tables, they may each 
be implemented using more than one table, or a combination of data structures of 
different types. 
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To more clearly illustrate the operation of the network, its operation is 
described herein in conjunction with an example of its use by a customer. Figure 7 is 
a screen shot diagram showing a Web page displayed by a merchant. The Web page 
700 includes information about the merchant, including information about products 
5 711-714 that are offered for sale by the merchant. The information about each item 
includes a link that may be activated by the customer. For example, link 71 1 may be 
activated by the customer to purchase the item "20 Questions on XML." When the 
customer does so, the customer initiates the purchasing process. 

Figure 8 is a flow diagram showing the steps preferably performed by 

10 the network as part of the purchasing process. These steps are preferably performed 
by network service center software executing on the network service center computer 
system and a transaction engine executing on the merchant computer system in 
conjunction with the Web browser executing on a customer computer system. Those 
skilled in the art will recognize, however, that these steps, as well as the other steps 

15 shown in flow diagrams herein, may also be distributed to other computer programs 
executing on other computer systems in accordance with alternate network 
configurations. 

In step 801, the network determines whether a valid session cookie is 
stored on the customer computer system in its cookie file 562. If so, this indicates 

20 that the customer computer system is being used by a registered customer who has 
already signed on to the network, and the network continues in step 807. Otherwise, 
no registered user is currently signed onto the network from the customer computer 
system, and the network continues in step 802. Step 801 is preferably performed by 
examining time stamps in any network session cookies previously stored on the 

25 customer computer system by the network. These time stamps reflect the last time 
the customer signed on and the last time the customer made a purchase. The amount 
of time elapsed between these times stored in the cookie and the present time 
indicates whether each session cookie is presently valid. For example, the network 
may determine that a cookie indicating that the customer signed on less than six hours 
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ago and completed his or her last purchase less than two hours ago is still signed onto 
the network, and that a network session cookie bearing those time stamps is valid. 

In step 802, if the customer is already registered with the network, the 
network permits the customer to sign on, and continues in step 803. If not, the 
5 network allows the user to register with the network, and continues in step 804. In 
step 803, the network authenticates the customer based on information provided by 
the customer as part of a sign on process. Figure 9 is a flow diagram showing the 
steps preferably performed by the network in order to authenticate a customer. In 
step 901, the network collects from the customer the customer's member identifier 

10 and password. Figure 10 is a screenshot diagram showing the sign on dialog box 
preferably displayed by the network to collect the member identifier and password. 
The sign on dialog box 1000 includes a member identifier field 1001 and a password 
field 1002, into which the customer may type his or her member identifier and 
password, respectively. The user then selects the sign on button 1003 to submit this 

15 information. 

In step 902, the network also reads a customer cookie stored on the 
customer computer system for the collected member identifier. In step 903, the 
network extracts from the read customer cookie a unique identifier for the user stored 
in the customer cookie by the network. In one preferred embodiment, this unique 

20 identifier is the user's email address, or other information specific to the domain of 
the user. In step 904, if the combination of the collected user name and the extracted 
unique identifier correspond to a customer entry in the customer database, then the 
network continues in step 905, else authentication fails. In step 905, if the collected 
password is the correct password for that customer entry in the customer database, 

25 then authentication succeeds, else authentication fails. 

Returning to Figure 8, in step 804, the customer has elected to register 
with the network by activating the register link 1004 in the sign on dialog box 1000. 
Figure 1 1 is a flow diagram showing the steps preferably performed by the network in 
order to register the customer with the network. In step 1101, the network collects 

30 personal information about the customer, as well as payment information. The 



BNSDOCID: <WO 0033221 A1 _!A> 



WO 00/33221 



18 



PCT/US99/27879 



payment information preferably specifies a credit card account, but may alternatively 
specify any method of payment selected by the operator of the network. The 
collection process is shown in Figure 12. Figure 12 is a screenshot diagram showing 
a registration dialog 1200, into which the user enters personal and payment 
5 information. The user preferably fills in a first name field 1201, a last name field 
1202, a postal code field 1203, an email address field 1204, a credit card type field 
1205, a credit card number field 1206, a credit card expiration date field 1207, a 
member ID field 1208, password fields 1209, and a shared secret field 1210. It 
should be noted that the member ID 1208 may be any member identifier selected by 
10 the user, and does not need to be unique across the network. After completing fields 
1200 through 1210, the user activates the register button 1211 to submit the 
information. 

Returning to Figure 11, in step 1102, the network verifies that the 
entered personal information is formatted correctly. For example, the network 

15 verifies that the zip code in the customer's address has the correct number of digits. 
If personal information formatting verification fails, the network preferably requests 
that the user input new, correctly-formatted personal information and repeats step 
1 102. In step 1 103, the network verifies the entered payment information. In doing 
so, the network preferably determines whether the credit card number is valid, and 

20 whether the personal information collected matches the credit card number. As part 
of determining whether the credit card is valid and active, the network may further 
attempt to obtain authorization to charge a small amount to the credit card, to ensure 
that the credit card is active. The network may further utilize third party credit card 
verification or fraud detection services in performing step 1103. If verification of 

25 payment information fails, the network preferably requests that the user input new, 
valid payment information and repeats step 1103. In step 1104, the network creates 
an entry in the customer database for the customer containing the collected 
information. In step 1105, the network sends an email message to the customer 
announcing the customer's successful registration with the network. After step 1 105, 

30 the steps conclude. 
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Returning to Figure 8, after registering the customer, in step 805, the 
network stores on the customer system a customer cookie identifying the customer by 
user name and unique identifier (preferably email address). In step 806, the network 
stores on the customer computer system a network session cookie documenting 
5 customer authentication. The network session cookie preferably includes the date and 
time of authentication. In step 807, the network determines whether the item selected 
by the customer has already been purchased by the customer. If so, the network 
continues in step 811 to provide the purchased item without charging the customer 
again. Otherwise, the network continues in step 808. In step 808, the network 

10 confirms the purchase with the customer. Figure 13 is a screenshot diagram showing 
a confirmation dialog preferably displayed by the network in step 808. The 
confirmation dialog 1300 contains information 1301 about the purchase, including an 
identification of the item, the purchase amount, and the duration or expiration of the 
purchase. In order to complete the purchase, the customer activates the continue 

15 button 1302. 

Returning to Figure 8, in step 809, the network generates a purchase 
transaction, which it adds to its transaction database 645. In step 810, the network 
updates the network session cookie stored on the customer computer system to reflect 
the present time as the time of the last purchase. In step 81 1, the network provides to 

20 the user the purchased item. After step 811, these steps conclude. 

Figure 14 is a screenshot diagram showing provision of a purchased 
item. The Web page 1400 is the purchased item selected by activating link 71 1 on 
the merchant Web page, "20 Questions on XML." If the user leaves this Web page to 
continue browsing or turns off the customer computer system, the customer can 

25 revisit this purchased item during the duration of the purchase by again selecting its 
link from the merchant Web page. In response, the network immediately provides the 
purchased item without further interaction by the customer once the user is 
authenticated by the network. 

After the customer is authenticated, the customer may complete 

30 additional purchases on the same or different merchant Web pages without 
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reauthenticating. Figure 1 5 is a screenshot diagram showing a Web page of a second 
merchant. The Web page 1500 lists items 1501-1526 available for purchase. The 
user may select link 1524 in order to select a market report item titled "Electrical 
Power Systems FY 98." After selection of this link, a confirmation dialog is 
5 immediately displayed without requiring the user to perform any authentication 
interactions. 

Figure 16 is a screenshot diagram showing the confirmation dialog 
displayed in response to the customer's activation of link 1524. Once the 
confirmation dialog box 1600 is displayed, the user need only select the continue 
10 button 1601 in order to complete the purchase of this additional item. After selecting 
this button, the "Electrical Power Systems FY 98" report is displayed. Figure 17 is a 
screenshot diagram showing the provision of the additional purchased item. Web 
page 1700 contains the purchased "Electrical Power Systems FY 98" item. 

As a result of each purchase transaction, the transaction engine creates 

15 a transaction record documenting the transaction, which is stored by the transaction 
engine at the merchant site. Periodically, a polling agent within the network service 
center software polls the transaction engine at each merchant site to retrieve any 
transaction records generated on that merchant's site. The polling agent, upon 
retrieving these transactions, stores them each as a row in a transaction database 

20 maintained by the network. The transaction records are preferably aggregated by the 
network periodically into payment requests, which are requests to a payment 
processor to charge the customer's credit card or other form of payment. Figure 18 is 
a table diagram showing the transaction database maintained by the network. While 
the transaction table is shown for clarity as a single database table containing plain 

25 text, it will be appreciated by those skilled in the art that it may be advantageously 
implemented in a more heavily encoded and optimized form using conventional 
database techniques. 

In the transaction table 1800, each row represents a transaction. Each 
row preferably contains data in at least six columns: a customer column 1801, a 

30 merchant column 1802, an item column 1803, an amount column 1804, an expiration 
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column 1805, and an outstanding column 1806. The customer column preferably 
contains the member ID of the customer that entered into the transaction. For 
example, row 1812 contains the member identifier "Joe User." The merchant column 
identifies the merchant with which the customer entered into the transaction. For 
5 example, row 1812 lists the merchant "Content Partner." The item column 1803 
preferably identifies the purchased item. For example, in row 1812, the item is the 
"Twenty Questions on XML" item. The price column 1 804 preferably contains the 
amount of the purchased item. For example, in row 1812, the price is "US$ 2.50". 
The expiration column 1805 preferably contains the time at which the purchase 

10 expires. For example, for row 1812, the purchase expires at 2:25 p.m. on 
Novembers, 1998. Finally, the outstanding column 1812 indicates whether the 
customer has yet paid for the purchase. For example, in row 1812, the customer has 
not yet paid for the purchase, so the transaction is still outstanding. 

Figure 19 is a flow diagram of the steps preferably performed by the 

15 network in order to aggregate the transaction records in the transaction database into 
payment requests sent to a payment processor. The transactions are preferably 
aggregated monthly on each customer's monthly billing anniversary, but may be 
aggregated on any other desired schedule. In steps 1901-1907, the network loops 
through each of a plurality of groups of customers. In a preferred embodiment, there 

20 is a separate group of customers for each day of the month, and the loop of steps 
1901-1907 is iterated once per day. In steps 1902-1905, the network loops through 
each customer in the group. In step 1903, the network determines the sum of the 
outstanding transactions of the customer. For example, for customer "Joe User" the 
network would add the amounts of rows 1812 and 1813, "US$ 2.50" and 4i US$ 1.00", 

25 to determine the sum of US$ 3.50. In step 1904, if the sum is greater than a billing 
threshold, such as US$ 4, then the network continues in step 1905, else the network 
continues in step 1906. In step 1905, the network generates a payment request for the 
determined sum against the credit card, or other form of payment, of the customer. In 
a preferred embodiment, the generated payment request has two parts: an 

30 authorization request, and a settlement request. The authorization request requests 
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the authority to charge the amount, while the settlement request requests actual 
payment of the amount. In step 1906, if additional customers remain for processing, 
the network loops to step 1902 to process the next customer in the group. In step 
1907, the network transmits the payment requests generated in step 1905 to a 
5 payment processor in a batch. In step 1908, each day, the network loops back to step 
1901 to process the next group of customers. 

Generally, for each batch of payment requests transmitted to the 
payment processor, a payment report is received back from the payment processor 
indicating whether each of the payment requests was paid. Figure 20 is a flow 
10 diagram showing the steps preferably performed by the network in order to process a 
payment report. In step 2001, the network receives the payment report from the 
payment processor. In steps 2002-2007, the network loops through each payment 
indication in the payment report. Each payment indication generally corresponds to a 
different one of the payment requests included in the batch. In step 2003, if the 
15 payment indication indicates that the corresponding authorization was paid by the 
payment processor, then the network continues in step 2005, else the network 
continues in step 2004. In step 2004, the network, through inaction, permits the 
constituent transaction records to remain outstanding. The network may also take 
further steps (not shown) to immediately resubmit the payment requests, or to cancel 
20 the account of the customer. After step 2004, the network continues in step 2007. In 
step 2005, the network credits the accounts of the merchants of the constituent 
transactions in accordance with the business arrangement between the merchants and 
the operator of the network. For example, the merchant "Stat USA" may have an 
arrangement with the operator of the network in which the merchant receives ninety 
25 percent of the amount of each purchase. Thus, for transaction record 1813, the 
merchant "Stat USA" would be credited in the amount US$ 0.90. In step 2006, the 
network cancels the outstanding status of the constituent transaction records so that 
they will not be incorporated in any future payment requests. In step 1907, if 
additional payment indications remain in the payment report, the network loops back 
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to step 1902 to process the next payment indication. After step 2007, the steps 
conclude. 

With respect to the steps shown in Figures 19 and 20 and discussed 
above, those skilled in the art will appreciate that, while these steps are directed 
5 primarily to forms of payment such as credit cards and check cards, these steps may 
be straightforwardly adapted to obtain payment from customers using different forms 
of payment. 

In preferred embodiments, tasks relating to customer authentication 
and purchasing are allocated within the network as follows. Each item purchase link 

10 is preferably directed to a portion of the network called the transaction engine. A 
separate transaction engine is preferably located at each merchant site, so that, at any 
time that customers are able to access the merchant Web pages to initiate a purchase 
transaction, a version of the transaction engine is available to conduct the purchase 
transaction. The transaction engine reads and writes network session cookies. In 

15 order to do so, the transaction engines for all of the merchants are preferably 
registered within a single, central domain so that all of the transaction engines at all 
of the merchant sites may read and write the same cookies on the customer computer 
system. When an item purchase link is activated, the transaction engine checks for a 
valid network session cookie on the customer computer system, indicating that the 

20 customer has already been authenticated. If the transaction engine does not find a 
valid network session cookie, the transaction engine redirects processing to a 
customer information subsystem of the network. The customer information 
subsystem portion of the network performs authentication or registration for the 
customer, then instructs the transaction engine to confirm the transaction, generate a 

25 transaction record, write or refresh the network session cookie, and deliver the 
purchased item. To deliver the purchased item, in one embodiment, the transaction 
engine retrieves the data for the item from the merchant, and delivers the data for the 
item to the customer. 

In another embodiment of the invention, in order to avoid the time and 

30 processing cost of relaying the data for the item through the transaction engine, rather 
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than itself retrieving the data for the item, the transaction engine sends a request to the 
merchant computer system, through the customer computer system, to transmit the 
data for the item directly to the user. The request includes a "ticket" — an encrypted 
token attesting to the legitimacy of the request. At the merchant computer system, an 
5 authorization subsystem decrypts and verifies the ticket, creates a merchant session 
cookie that is similar to the network session cookie and that attests to the purchase 
and the authentication of the customer, and transmits the data for the item to the 
customer computer system. 

Locating authorization subsystems at merchant computer systems also 

10 enables the network to manage customer authentication for merchants in their own 
domains. When a customer attempts to access a restricted portion of a merchant's 
Web site that is in a domain other than the central domain of the network, the 
authorization subsystem on the merchant computer system for that merchant checks 
to see whether a valid merchant cookie for that merchant is present on the customer 

15 computer system. Such a merchant cookie, if it is present on the customer computer 
system, attests to the current authentication of the user by the merchant. If a valid 
merchant cookie for that merchant is present on the customer computer system, the 
authorization subsystem allows access to the restricted portion of the merchant's Web 
site. If not, the authorization subsystem contacts the transaction engine. If the 

20 transaction engine finds a valid network session cookie on the customer machine — 
that is, a cookie attesting to the authentication of the customer in the central 
domain — it instructs the authorization subsystem to write a merchant session cookie 
and permit access to the restricted portion in the merchant's domain. 

In a manner similar to the purchase process, if the transaction engine 

25 does not find a network session cookie on the customer machine, the transaction 
engine redirects processing to the customer information subsystem of the network. 
The customer information subsystem portion of the network performs authentication 
or registration for the customer, then instructs the transaction engine to create a 
network session cookie to the customer computer system. The transaction engine 

30 further instructs the authorization subsystem to write a merchant session cookie and 
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permit access to the restricted portion. In this way, the network provides a common 
method for signing onto the Web sites of all of the merchants, even those with 
restricted portions outside of the central network domain. Further, a customer may 
visit restricted areas of several different merchants, and is only required to sign on 
5 once. 

In addition to some or all of the foregoing features, the network 
additionally preferably provides customers with centralized, automated services for 
account management, product refunds, subscription management, and multiple 
purchasing accounts linked to the same payment account. 

10 Figures 21-25 illustrate the automated product refund service 

preferably provided by the network. Figure 21 is a screenshot diagram showing a 
sample customer statement. The statement 2100 contains entries, such as entries 
2110 and 2120, each containing information about an item purchased by the customer 
named "Joe User." For example, entry 2120 in the statement contains information 

15 about the "Electrical Power Systems FX 98" report purchased from "Stat USA." The 
statement further includes the current balance 21 30 for this account. 

Each entry includes a link for displaying additional detail about the 
purchased item. For example, entry 2120 includes link 2121, which the user may 
activate to display additional information about the Stat USA report. Figure 22 is a 

20 screenshot diagram showing a sample item information page. The item information 
page 2200 includes information 2210 about the item. This information includes a 
link 221 1 that can be activated to access the purchased item. The item information 
page also includes a button 2220 that can be activated to request a refund for the item. 
A customer may wish to request a refund, for example, if the item was ordered by 

25 mistake, if the item does not conform to the customer's expectations, or if the item 
could not be properly downloaded. 

Figure 23 is a screenshot diagram showing a sample refund request. 
The refund request 2300 is displayed in response to the customer's activation of 
button 2340. The refund request contains information 2310 about the item for which 

30 a refund is sought, a listbox 2320 for specifying a reason for the refund request, and a 
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field 2330 for entering a further explanation of the circumstances surrounding the 
request for refund. The refund request further contains a button 2340 that can be 
activated to submit the refund request. Figure 24 is a screenshot diagram showing a 
sample confirmation screen confirming a refund request. The confirmation screen 
5 2400 is preferably displayed in response to the activation of button 2340. 

After the refund request is submitted, the customer's statement is 
preferably updated to reflect the submission of the refund request. Figure 25 is a 
screenshot diagram showing a sample statement reflecting the submission of a refund 
request. The updated statement 2500 includes a line 2521 indicating that a refund has 
10 been requested for item 2520. Line 2521 further indicates that the price of item 2520 ? 
$1.00, is being deducted from the account balance while the refund request is being 
considered. As a result, the account balance 2530 is reduced to include only the price 
of item 2510. 

In processing refund requests, the network preferably employs a 

15 maximum automatic refund threshold. If a refund request is directed to an item 
having a price that is less than the maximum automatic refund threshold, the network 
preferably automatically grants the refund request. On the other hand, the network 
applies a more rigorous evaluation process to refund requests that are directed to 
items having prices greater than the maximum automatic refund threshold. The 

20 network preferably forwards such refund requests to a human customer service 
representative. This use of a maximum automatic refund threshold reflects a 
recognition that evaluation by a human customer service representative may incur a 
significant cost that, in many cases, exceeds the cost of granting the refund. In a 
preferred embodiment, the maximum automatic refund threshold is set at $10.00. As 

25 a result, a customer may conveniently complete the submission of a refund request 
without interacting directly with a human customer service representative. Further, in 
most cases, the network relieves its operator of any need to expend customer service 
representative time to process refund requests. 

Figures 26-27 illustrate the automated, centralized subscription 

30 management service preferably provided by the network. Figure 26 is a screenshot 
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diagram showing a sample subscription management page. The subscription 
management page 2600 contains entries, such as entries 2610 and 2620, each 
containing information about a subscription purchased by the customer named "Joe 
User." For example, entry 2610 in the subscription management page contains 
5 information about a subscription to the "Wall Street Journal." Each entry also 
includes an indication of the expiration date of the subscription, as well as an 
indication of whether the subscription will automatically renew when it expires. 

Each entry includes a link for displaying information about or 
modifying the subscription. For example, entry 2610 includes link 261 1, which the 

10 user may activate to display additional information about the Wall Street Journal 
subscription. Figure 27 is a screenshot diagram showing a sample subscription 
information page. The subscription information page 2700 includes information 2710 
about the subscription. This information includes a link 271 1 that can be activated to 
access the subscription. The item information page also includes buttons 2721-2723 

15 for modifying the subscription. The user may activate button 2721 to immediately 
renew the subscription for another term. When button 2721 is activated, the network 
updates the subscription management and subscription information pages to extend 
the expiration date of the subscription by the length of a term, and notifies the 
transaction engine at the merchant site to update the status of the subscription. The 

20 user may activate button 2722 to specify that the subscription should automatically 
renew for another term when the present term expires. When button 2722 is activated, 
the network updates the subscription management and subscription information pages 
to indicate that the subscription will automatically renew, and notifies the transaction 
engine at the merchant site to update the status of the subscription. The user may 

25 activate button 2723 to cancel the subscription. When button 2722 is activated, the 
network preferably credits the customer's account for a pro-rated portion of the 
subscription price. The network further updates the subscription management page to 
remove the entry for this subscription, and notifies the transaction engine at the 
merchant site to update the status of the subscription. 
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As a result, a customer may conveniently perform subscription 
management operations without interacting directly with a human customer service 
representative. Further, the network relieves its operator of any need to expend 
customer service representative time to process subscription management operations. 
5 In order to facilitate purchasing by multiple customers who pay for 

purchases together, the network preferably provides a feature in which it associates 
multiple purchasing accounts with a single payment account. This feature enables a 
company to pay for and track the purchases of its employees, a parent to pay for and 
track the purchases of his or her children, or an individual to separate his or her 

10 business purchases from his or her personal purchases. In accordance with this 
feature, a first customer may register as described above, in order to obtain both a 
purchasing account for purchasing items, and a payment account for paying for those 
purchases. At a later time, the first customer may create additional purchasing 
accounts that are "associated" with the payment account, either for others, or for 

15 himself or herself Any purchases made with an additional purchasing account are 
consumed using the additional purchasing account, and are billed to the associated 
payment account, using the payment information associated with this payment 
account. 

Figures 28-30 illustrate the multiple purchasing accounts feature 
20 preferably provided by the network. In a preferred embodiment, an additional 
purchasing account can be added to an existing payment account by a customer 
signed on to an existing purchasing account associated with the payment account. 
Figure 28 is a screenshot diagram showing a sample registration page for registering 
an additional purchasing account for an existing payment account. In the example, 
25 the registration page shown is used by the customer named "Joe User" to add an 
additional purchasing account for "Jean User" to his existing payment account. The 
registration page contains fields 2810 into which the customer enters information 
about the customer that will use the additional purchasing account, including the 
email address of this customer, and the user name and password to be used with the 
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additional purchasing account. After entering this information, the customer activates 
button 2820 to register the additional purchasing account- 
After the additional purchasing account has been registered, it may be 
used by Jean User to purchase items. Figure 29 is a screenshot diagram showing a 
5 sample customer statement showing purchases made with the additional purchasing 
account. The customer statement 2900 contains entries 2910 and 2920 for items 
purchased by Jean User using her purchasing account. The customer statement 
further contains a total 2930 of the items that Jean User has purchased. It should be 
noted that, in the preferred embodiment shown, items purchased using other 

10 purchasing accounts associated with the same payment account (e.g., those purchased 
by Joe User using his purchase account, shown in Figure 21) are not shown on the 
customer statement or included in the total. 

On the other hand, customers signed on to the payment account (or to 
the first purchasing account, which is preferably more tightly coupled to the payment 

15 account than are additional purchasing accounts) may display the purchases made 
using other customer accounts associated with the same payment account. Figure 30 
is a screenshot diagram showing a sample customer statement showing purchases 
made with multiple purchasing accounts that are each associated with the same 
payment account. The customer statement 3000 includes both entries 3010 and 3020 

20 describing purchases made by Joe User using his purchasing account, and entries 
3030 and 3040 describing purchases made by Jean User using her purchasing 
account. Additionally, the customer statement shows a total 3050 that reflects the 
purchases made by both Joe User and Jean User. It can be seen that this statement 
permits a user of a payment account to review the purchases made using all of the 

25 purchasing accounts associated with the payment account, and to determine the 
amount that will requested in the next payment request generated by the network for 
the payment account. 

While this invention has been shown and described with reference to 
preferred embodiments, it will be understood by those skilled in the art that various 

30 changes or modifications in form and detail may be made without departing from the 
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scope of the invention. For example, instead of operating in conjunction with 
multiple merchants, the network may operate in conjunction with a single merchant. 
Further, the functionalities provided by the network may be allocated differently 
across the described computer systems, or may be provided by a different 
5 combination of computer systems than described. Further, these computer systems 
may be connected by a combination of different networks, instead of by a single 
network such as the Internet. The network may further be reconfigured to more 
optimally perform in particular business environments. Additionally, the network 
may be used to sell goods and services other than digital goods, including physical 
10 goods. Also, the network may preferably accept payment information and generate 
payment requests for any form of payment, or any combination of different forms of 
payment. 
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CLAIMS 

We claim: 



1 1. A method in a computer network for managing purchase 

2 transactions for the Web sites of a plurality of merchants using a transaction network, 

3 comprising the steps of: 

4 for each of the plurality of merchant Web sites, under the control^of the 

5 merchant Web site: 

6 displaying items available for purchase, each item having a price; 

7 receiving user input from users using Web clients selecting items 

8 for purchase; and 

9 for each item selection, forwarding a purchase request to the 

10 transaction network indicating the price of the selected item; 

1 1 under the control of the transaction network: 

12 receiving transaction network purchase requests forwarded from 

13 the plurality of merchant Web sites; 

14 for each received purchase request: 

1 5 discerning the identity of the user; and 

16 generating a pending transaction record indicating the 

17 identity of the user, the price of the selected item, and the identity of the forwarding 

1 8 Web site; 

19 periodically determining, for each user whose identity is 

20 indicated by a pending transaction record, the sum of the prices of the pending 

2 1 transaction records indicating the identity of the user; 

22 where the determined sum for a user exceeds a billing threshold, 

23 submitting to a payment processor a request for settlement for the determined sum 

24 against an account of the user; 

25 receiving settlement indications from the payment processor each 

26 indicating payment of an identified submitted a request for settlement; 
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27 for each received settlement indication, for each transaction 

28 record whose price is included in the sum of the billing transaction identified by the 

29 received settlement indication: 

30 crediting an account of the merchant identified by the 

3 1 transaction record; and 

32 removing the pending status of the transaction record. 

1 2. A method in one or more computer systems for procuring 

2 payment for purchase transactions each originating with a particular user and vendor. 

3 comprising the steps of: 

4 receiving purchase requests each originating at one of a plurality of 

5 vendor Web sites, each purchase request indicating a purchase price; 

6 for each received purchase request: 

7 discerning the identity of a user with which the purchase request 

8 originated; and 

9 storing a pending transaction record indicating the identity of the 

10 user, the purchase price, and the identity of the vendor at whose Web site the purchase 

1 1 request originated; 

12 periodically determining, for each user whose identity is indicated by a 

13 pending transaction record, the sum of the prices of the pending transaction records 

14 indicating the identity of the user; 

15 where the determined sum for a user exceeds a billing threshold, 

16 submitting to a payment processor a billing transaction for the determined sum against 
-17 an account of the user; 

18 receiving settlement indications from the payment processor each 

19 indicating payment of an identified submitted billing transaction; 

20 for each received settlement indication, for each transaction record 



21 whose price is included in the sum of the billing transaction identified by the received 

22 settlement indication: 
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23 crediting an account of the vendor identified by the 

24 transaction record; and 

25 removing the pending status of the transaction record. 

1 3. One or more computer memories collectively containing a data 

2 structure for purchasing items from different vendors, the data structure comprising: 

3 a first Web page, under the control of a first vendor, containing 

4 information describing a first item and a first link to a purchasing system not under the 

5 control of the first vendor, the first link activatable by users to purchase the first item; 

6 a second Web page, under the control of a second vendor distinct from 

7 the first vendor, containing information describing a second item and a second link to 

8 the purchasing system, the purchasing system also not under the control of the second 

9 vendor, the second link activatable by users to purchase the second item; 

10 instructions stored in a purchasing system, the instructions responding to 

1 1 the activation of the first link by: 

12 identifying the user activating the first link; 

13 establishing an account for the identified user if one has not yet 

14 been established; 

15 causing the purchase of the first item to be posted to the account 

16 of the identified user; and 

17 providing the first item to the identified user, 

18 the instructions responding to the activation of the second link by: 

19 identifying the user activating the second link; 

-20 establishing an account for the identified user if one has not yet 

21 been established; 

22 causing the purchase of the second item to be posted to the 

23 account of the identified user; and 

24 providing the second item to the identified user. 
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1 4. The computer memories of claim 3 wherein the instructions 

2 stored on the purchasing system are provided in an active server object. 

1 5. A method in a computer system for generating payment requests 

2 incorporating multiple purchase transactions, comprising the steps of: 

3 receiving purchase transaction indications, each purchase transaction 

4 indication indicating an amount and identifying one of a plurality of customers; 

5 for each customer: 

6 periodically determining the sum of the amounts of the received 

7 purchase transaction indications identifying the customer that have not been 

8 incorporated in a payment request; and 

9 when the determined sum exceeds a billing threshold, generating 



10 a new payment request for the customer in the amount of the sum that incorporates the 

1 1 received purchase transaction indications identifying the customer that have not been 

12 incorporated in a payment request. 



1 6. The method of claim 5 wherein the receiving step receives 

2 purchase transaction indications from a number of different vendors often whom the 

3 customers have made purchases. 

1 7. The method of claim 6, further comprising the steps of: 

2 for each vendor, collecting transaction indications indicating transactions 

3 entered into with the vendor; and 

4 retrieving the collected transaction indications from each vendor. 

1 8. The method of claim 5 wherein the generating step generates 

2 settlement requests, and wherein the method further comprises the step of transmitting 

3 generated settlement requests to a payment processor for settlement. 
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1 9. A computer-readable medium whose contents cause a computer 

2 system to generate billing transactions incorporating multiple purchase transactions by 

3 performing the steps of: 

4 receiving purchase transaction indications, each purchase transaction 

5 indication indicating an amount and identifying one of a plurality of customers; and 

6 for each customer: 

7 periodically determining the sum of the amounts of the received 

8 purchase transaction indications identifying the customer that have not been 

9 incorporated in a billing transaction; and 

10 when the determined sum exceeds a billing threshold, generating 

1 1 a new billing transaction for the customer in the amount of the sum that incorporates the 

12 received purchase transaction indications identifying the customer that have not been 
i 3 incorporated in a billing transaction. 

1 10. The computer-readable medium of claim 9 wherein the receiving 

2 step receives purchase transaction indications from a number of different content 

3 providers with whom the customers have entered into purchase transactions. 

1 11. A computer system for generating billing transactions 

2 incorporating multiple purchase transactions, comprising: 

3 a receiver that receives purchase transaction indications, each purchase 

4 transaction indication indicating an amount and identifying one of a plurality of 

5 customers; 

6 an adder that, for each customer, periodically determines the sum of the 

7 amounts of the received purchase transaction indications received by the receiver that 

8 identify the customer that have not been incorporated in a billing transaction; and 

9 a billing transaction generator that, when the sum determined by the 

10 adder exceeds a billing threshold, generates a new billing transaction for the customer in 
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1 1 the amount of the sum that incorporates the received purchase transaction indications 

12 identifying the customer that have not been incorporated in a billing transaction. 



1 12. A method in a computer system for aggregating charge 

2 transactions entered into by a customer, the method comprising the steps of: 

3 over time, receiving a stream of charge transactions entered into by the 

4 customer, each charge transaction having an amount; 

5 identifying a time at which the sum of the amounts of the received 

6 charge transactions exceeds a threshold amount; and 

7 submitting to a payment processor a payment request for the sum of the 

8 received charge transactions. 

1 13. The method of claim 12 wherein one of the received charge 

2 transactions was entered into in conjunction with a third-party vendor, further 

3 comprising the steps of: 

4 receiving from the payment processor, in response to the submitting step, 

5 a settlement indication indicating payment of the submitted payment request; and 

6 in response to the step of receiving a settlement indication, crediting to 

7 the vendor a portion of the sum. 

1 14. A computer-readable medium whose contents cause a computer 

2 system to process charge transactions entered into by a customer by performing the 

3 steps of: 

- 4 receiving a stream of charge transactions entered into by the customer, 

5 each charge transaction having an amount; 

6 identifying a time at which the sum of the amounts of the received 

7 charge transactions exceeds a threshold amount; and 

8 submitting to a payment processor a settlement request for the sum of the 

9 received charge transactions. 
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1 15. The computer-readable medium of claim 14 wherein one of the 

2 received charge transactions was entered into in conjunction with a third-party vendor, 

3 and wherein the contents of the computer-readable medium further cause the computer 

4 system to perform the steps of: 

5 receiving from the payment processor, in response to the submitting step, 

6 a payment indication indicating payment of the submitted settlement request; and 

7 in response to the receiving step, crediting to the vendor a portion of the 

8 sum. 

1 16. A computer memory device storing a charge aggregation data 

2 structure for storing information about charge transactions directed to a particular form 

3 of payment, the form of payment having a minimum threshold for charges against the 

4 form of payment, the data structure comprising a plurality of records each representing 

5 a distinct charge transaction, each record indicating an amount for the transaction it 

6 represents, at least some of the records indicating amounts below the minimum 

7 threshold for the form of payment, 

8 such that the data structure may be accessed to combine a plurality of the charge 

9 transactions into a single aggregate transaction having an amount corresponding to the 

10 combined amounts indicated by the records that is in excess of the minimum threshold, 

1 1 such that the aggregate transaction may be charged against the form of payment. 



17. The computer memory device of claim 16 wherein the form of 
payment is a credit card. 



1 18. The computer memory device of claim 16 wherein the form of 

payment is a debit card. 



19. The computer memory device of claim 16 wherein the form of 
payment is an automated clearing house payment. 
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1 20. The computer memory device of claim 16 wherein the form of 

2 payment is an electronic funds transfer transaction. 

1 21. The computer memory device of claim 16 wherein the form of 

2 the payment is a purchase order. 

1 22. The computer memory device of claim 16 wherein each record of 



2 the data structures identifies one of a plurality of customers as having entered into the 

3 transaction represented by the record, 

4 such that the data structure may be accessed to combine a plurality of the charge 

5 transactions into a plurality single aggregate transactions each corresponding to a single 

6 customer. 



1 23. A memory device storing an aggregate charge data structure, the 

2 aggregate charge data structure being suitable for submission to a payment processor for 

3 payment, the data structure comprising: 

4 a consumer identifier identifying a consumer that has charged a 

5 multiplicity of purchase transactions, each purchase transaction having an amount; and 

6 an aggregate charged amount constituting the sum of the amounts of a 



7 constituent plurality of the multiplicity of purchase transactions charged by the 

8 consumer, at least one of the amounts of the constituent purchase transactions falling 

9 below a minimum threshold for submitting charges to a payment processor for payment, 
- 10 such that the data structure may be submitted to a payment processor for payment in 

1 1 place of the constituent purchase transactions. 

1 24. The memory device of claim 23 wherein the data structure further 

2 comprises both a consumer identifier and aggregate charged amount for each of a 

3 plurality of additional consumers. 
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1 25. A method in a computer system for identifying a user using a 

2 user computer system among a group of users, the method using a potentially non- 

3 unique member identifier, the method comprising the steps of: 

4 (a) registering the user by: 

5 (1) obtaining for the user a member identifier that is potentially 

6 not unique; 

7 (2) after obtaining the solicited member identifier in step (a)(1), 

8 storing a unique identifier for the user on the user computer system in conjunction with 

9 the obtained member identifier; and 

10 (b) identifying the user by: 

M (1) soliciting from the user the member identifier of the user; 

12 (2) receiving from the user, in response to step (b)(1), the 

13 member identifier of the user; 

14 (3) reading from the user computer system the unique identifier 

15 stored in conjunction with the member identifier received in step (b)(2); 

16 (4) identifying the user using the unique identifier read in step 

17 (b)(3). 

1 26. The method of claim 25 wherein a plurality of users having the 

2 same user computer system are registered by repeating steps (a)(l)-(a)(2) for each of the 

3 plurality of users. 



1 27. The method of claim 25 wherein obtaining step (a)(1) comprises 

2 the steps of: 

3 soliciting from the user a member identifier of the user; and 

4 receiving from the user a member identifier of the user. 

1 28. The method of claim 25 wherein the method is practiced on 

2 behalf of a first online service, and wherein obtaining step (a)(1) comprises the step of 
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3 obtaining for the user a member identifier used by the user to identify himself or herself 

4 to second online service distinct from the first online service. 



1 29. The method of claim 28 wherein the step of obtaining for the user 

2 a member identifier used by the user to identify himself or herself to second online 

3 service obtains the member identifier from an operator of the second online service. 

I 30. A method in one or more computer systems for purchasing 



2 products offered for sale by multiple vendors, comprising the steps of: 

3 receiving a single, contiguous set of user interface interactions for 

4 establishing the identity of the user; 

5 establishing the identity of the user based on the single, contiguous set of 

6 user interface interactions received in the receiving step; 



7 purchasing an item offered for sale by a first vendor based on the user 

8 identity established in the establishing step; and 

9 purchasing an item offered for sale by a second vendor distinct from the 
10 first vendor based on the user identity established in the establishing step. 

1 31. The method of claim 30, further comprising the steps of: 

2 in conjunction with the step of purchasing an item offered for sale by a 

3 first vendor, displaying a visual indication of the first vendor; and 

4 in conjunction with the steps of purchasing an item offered for sale by a 

5 second vendor, displaying a visual indication of the second vendor. 

6 32. The method of claim 30 wherein the receiving and establishing 

7 steps are performed as part of the step of purchasing an item offered for sale by the first 

8 vendor. 

1 33. The method of claim 30 wherein the second vendor has a 

2 computer system, and wherein the establishing step includes the step of storing a central 



r 
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3 state signifying the establishment of the identity of the user, and wherein the step of 

4 purchasing an item offered for sale by the second vendor include the steps of: 

5 checking the stored state; 

6 in response to checking the stored state, sending an encoded ticket to the 

7 second computer system; 

8 under the control of the second computer system: 

9 decoding the encoded ticket; 

10 validating the decoded ticket; and 

1 1 performing the step of purchasing an item offered for sale by the 

12 second vendor in response to the validating step. 

1 34. The method of claim 30 wherein the establishing step includes 

2 the step of storing a central state signifying the establishment of the identity of the user, 

3 and wherein the step of purchasing an item offered for sale by a second vendor include 

4 the steps of: 

5 checking the stored central state; and 

6 performing the step of purchasing an item offered for sale by a second 

7 vendor in response to the checking step. 

1 35. A method in one or more computer systems for accessing 

2 multiple access-restricted Web sites, comprising the steps of: 

3 receiving a single, contiguous set of user interface interactions for 

4 establishing the identity of the user; 

5 establishing the identity of the user based on the single, contiguous set of 

6 user interface interactions received in the receiving step; 

7 granting access to a first access-restricted Web site based on the user 

8 identity established in the establishing step; and 

9 granting access to a second access-restricted Web site distinct from the 

10 second access-restricted Web site based on the user identity established in the 

1 1 establishing step. 
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1 36. The method of claim 35, wherein the second access-restricted 

2 Web site is served by a second computer system, and wherein the establishing step 

3 includes the step of storing a state signifying the establishment of the identity of the 

4 user, and wherein the step of granting access to the second access-restricted Web site 

5 include the steps of: 

6 checking the stored state; 

7 in response to checking the stored state, sending an encoded ticket to the 

8 second computer system; 

9 under the control of the second computer system: 
10 decoding the encoded ticket; 

! i validating the decoded ticket; and 

12 performing the step of granting access to the second access- 

13 restricted Web site in response to the validating step. 

1 37. The method of claim 35 wherein the establishing step includes 

2 the step of storing a central state signifying the establishment of the identity of the user, 

3 and wherein the step of granting access to the second access-restricted Web site include 

4 the steps of: 

5 checking the stored central state; and 

6 performing the step of granting access to the second access-restricted 

7 Web site in response to the checking step. 

1 38. A transaction network for vending digital content from a plurality 

2 of merchants comprising: 

3 for each merchant, a transaction engine for conducting transactions with 

4 customers to purchase digital content and deliver purchased digital content; and 

5 a network service center for collecting indicia of transactions entered 

6 into with each merchant and submitting payment requests for the collected transactions 

7 to a payment processor. 
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1 39. The transaction network of claim 38 wherein the network service 

2 center aggregates the transactions conducted with each customer, and wherein the 

3 payment requests are submitted for the aggregated transactions. 

1 40. The transaction network of 39 wherein the network service center 



2 further receives from the payment processor indications of the payment of the submitted 

3 payment requests, and, for each received indication, credits the merchants with which 

4 the transactions aggregated into the request where conducted. 



1 41. A method in one or more computer systems for providing to a 

2 customer automatic refund support for a purchase transaction, the method comprising: 

3 generating for the customer a display soliciting information supporting a 

4 request for refund of the purchase transaction; 

5 receiving from the customer, in response to the generated display, 

6 information supporting a request for refund; and 

7 automatically generating a request for refund incorporating the received 



8 information, 

9 such that the customer requests a refund of the purchase transaction without additional 
10 interaction. 



1 42. The method of claim 41, further comprising the steps of: 

2 generating for the customer a display containing indicators of each of a 

3 plurality of transactions entered into by the customer, at least two of the plurality of 

4 transaction being entered into with different merchants; and 

5 receiving from the customer a selection of the transaction indication of a 

6 selected transaction, 

7 and wherein the step of generating a display soliciting information to support a request 

8 for refund of a service transaction generates a display soliciting information to support a 

9 request for refund of the selected transaction. 
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1 43. The method of claim 41 wherein the transaction has an amount, 

2 the method further comprising the steps of: 

3 determining whether the amount of the transaction is less than a 

4 maximum threshold; and 

5 if the amount of the transaction is less than the maximum threshold, 

6 automatically granting the requests for refund. 

1 44. The method of claim 43, further comprising the step of, if the 

2 amount of the transaction is not less than the maximum threshold, determining whether 

3 to grant the request for refund based upon the information supporting the request for 

4 refund. 

1 45. A method in one or more computer systems for enabling a 

2 subscriber to manage content subscriptions from a plurality of content sources, the 

3 method comprising: 

4 displaying for the subscriber an indication of each of a plurality of 

5 content subscriptions entered into by the subscriber, at least two of the content 

6 subscriptions being with different content sources; 

7 receiving from the subscriber a selection of the indication of a selected 

8 content subscription; and 

9 on behalf of the subscriber, performing a subscription management 
10 operation with respect to the selected content subscription. 

1 46. The method of claim 45 wherein the performing step cancels the 

2 selected content subscription. 

1 47. The method of claim 45 wherein the performing step renews the 

2 selected content subscription. 
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1 48. A method in one or more computer systems for providing a 

2 plurality of purchasing accounts for purchasing digital content, all of the purchasing 

3 accounts of the plurality being associated with a single payment account, the method 

4 comprising: 

5 storing payment information for the payment account that is usable to 

6 procure payment for digital content purchases made using any of the plurality of 

7 purchasing accounts; 

8 storing for each of the purchasing accounts a different account identifier; 

9 iii response to each purchase request specifying content received in 

10 connection with the account identifier of one of the purchasing accounts: 

1 1 completing a purchase of the specified content, and 

12 providing the specified content; and 

13 utilizing the payment information stored for the payment account to 

14 procure payment for digital content purchases completed using any of the plurality of 

1 5 purchasing accounts. 

1 49. The method of claim 48, further comprising the steps of: 

2 storing an account identifier for the payment account; and 

3 in response to a request received in connection with the account 

4 identifier for the payment account, displaying information describing the purchases 

5 completed using any of the plurality of purchasing accounts. 

1 50. The method of claim 48, further comprising the step of, in 

2 response to a request received in connection with the account identifier for a selected 

3 one of the purchasing accounts, displaying information describing the purchases made 

4 completed using only the selected purchasing account. 
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